c# - INotifyPropertyChanged - 数据访问、业务或 UI 层

Question

我和一些同事就实现 INotifyPropertyChanged 的​​最佳层进行了一些讨论。场景如下:

• 数据访问层返回简单对象的集合
• 业务层处理对象并执行额外的验证等
• UI 层绑定(bind)到对象并使用 INotifyPropertyChanged 进行更改跟踪

这里的场景是DA层返回的数据和UI层消费的数据是一样的。我们是在 UI 层中实现 INotifyPropertyChanged，从而在不同层中拥有同一对象的多个近乎克隆，还是在 DA 层中实现 INotifyPropertyChanged，从而为与属性更改跟踪无关的层增加不必要的复杂性。

问题:

• 为 DA、业务和 UI 层使用单独的对象很干净，但增加了很多冗余
• 在 DA 中实现 INotifyPropertyChanged 感觉不对，因为 DA 不关心这个概念，可能会耦合 DA 和 UI 层

在这种情况下，我个人的偏好是:

public class DaObject
{
    public virtual string Value { get; set; }
}

// May or may not need a business object here. DA and UI may be enough.
public class BusinessObject : DaObject
{
    // Business layer logic/validation here...
}

public class UiObject : BusinessObject, INotifyPropertyChanged
{
    public override string Value
    {
        get { return base.Value; }
        set
        {
            base.Value = value;
            NotifyOfPropertyChanged(nameof(Value));
        }
    }

    // INotifyPropertyChanged implementation here...
}

谢谢!

Answer 1

INotifyPropertyChanged 的​​目的是通知客户端属性已更改。在大多数情况下，客户端将是一个绑定(bind)客户端，例如 UI 层。

在业务逻辑或数据访问层中实现 INotifyPropertyChanged 的​​危险在于您会增加复杂性并可能增加潜在的性能问题，从长远来看可能会削弱您的应用程序。

我会说 - 仅仅因为你可以做某事，并不意味着你应该做。

这个问题已经有 4 年历史了，我开始阅读它的原因是因为我正在处理在业务逻辑/数据访问层上实现 INotifyPropertyChanged 的​​遗留应用程序。结果，我们拥有大量包含不必要事件的对象，并严重影响了性能。

我发现保持业务逻辑和业务对象清洁要好得多，只在必要时在 View 模型上使用 INotifyPropertyChanged。