InotifyPropertychanged-数据访问，业务或UI层

Question

我们本人与一些同事之间的讨论是关于实现InotifyPropertychanged的最佳层次。这是场景：

• 数据访问层返回简单对象的集合
• 业务层按摩对象并执行额外的验证，等等
• UI层与对象结合并使用InotifyPropertyChanged进行更改跟踪

这里的情况是，DA层返回的数据与UI层消耗的数据相同。我们是否在UI层中实现了InotifyPropertychangy，因此在不同层中具有相同对象的多个近词，或者我们在DA层中实现了InotifyPropertychangy，从而在与属性变化跟踪有关的层中添加了不必要的复杂性。

关注：

• 有一个单独的DA，Business和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的目的是通知客户属性已更改。在大多数情况下，客户端将是绑定客户端，例如UI层。

在业务逻辑或数据访问层中实施InotifyPropertychange的危险是您正在添加复杂性，并可能添加潜在的性能问题，这些问题可能会长期削弱您的应用程序。

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

这个问题已经4年了，我之所以阅读它的原因是，我正在研究在业务逻辑/数据访问层上实现InotifyPropertychangy的旧应用程序。结果，我们有很多不必要的事件的物体集合，并且表现可怕。

我发现保持业务逻辑和业务对象保持清洁好多，只能在必要时使用视图模型上的InotifyPropertychangy。