如何/在何处将业务规则应用于POCO对象

本文关键字：应用于 POCO 对象 规则 业务 在何处 如何 | 更新日期: 2023-09-27 17:50:14

假设我有一个POCO，内容如下:

    [DataMember]
    public Nullable<int> MetricId
    {
        get { return _metricId; }
        set
        {
            if (_metricId != value)
            {
                _metricId = value;
                OnPropertyChanged("MetricId");
            }
        }
    }
    private Nullable<int> _metricId;

我想验证MetricId严格大于0

显然，如果我把这个规则作为数据注释放在这个类中，它将在下次重新生成poco时被覆盖。我该把这个逻辑放在哪里呢?

谢谢!

如何/在何处将业务规则应用于POCO对象

我似乎记得建议是利用部分类并滚动实现您不想被覆盖的逻辑的部分类。

在阅读了评论和响应之后，似乎创建另一个类是可以的，但是通过使它成为部分，它将我的业务逻辑直接绑定到实体框架和生成的POCO代码。这是令人担忧的，因为随着EF4更改为EF5, T4模板更改为T5模板，我的代码会发生什么?另外，我只是觉得把部分类当作普通类使用不舒服。

相反，有人仍然可以提供一个更好的答案(请这样做)，我认为创建一个框架独立的对象(不绑定到EF)是更好的。然后我可以将其映射到通用业务对象。比如:

    static Customer Map(CustomerPOCO poco)
    {
        return new Customer
        {
            CustomerId = poco.CustomerId
            ...
            ...
        };
    }

使用分部类是不干净的，比如你有产品抽象类和派生类在线产品和存储产品。两者都继承价格属性，但价格不同。假设业务逻辑也可能不同。现在你又多了两门其实并不需要的课。在更大的系统中，它会成倍增加。

相关文章：