在软件体系结构中应在哪里实现INotifyPropertyChanged接口？

Question

我目前正在创建一个项目，该项目的规模足以将其体系结构中的知名层仔细分离。

对于数据访问层（DAL），我仅使用.NET实体框架。

对于业务层，我定义了业务对象，随后的开发人员可以使用这些业务对象，他们可以使用它们创建客户端并处理UI。

由于我还必须开发一个客户端应用程序以进行演示，因此我意识到使用ObservableCollection<T>而不是列表可能会非常有帮助，并且对象应尽可能多地实现INotifyPropertyChanged接口，以便UI自动检测更改并立即显示更新。

但是，我想知道从架构的角度来看这是否真的是正确的方法。 也就是说，从技术上讲 ，我认为业务层不应该与UI显示有关，因为我们并不真正“知道”程序员可能将其用于什么； 例如，他可能只想将这些对象用于计算目的。 因此，我想知道什么是惯例？

我应该在业务层中实现这些功能吗（不会有性能问题）？ 我是否应该在包含所有这些功能的另一层中创建某种“装饰器”对象？

Answer 1

正如Skliwz在评论中提到的那样 ，正确的放置位置是在专门绑定到UI层的对象中。

如果您将业务对象直接绑定到UI层，并且发现INotifyPropertyChanged接口实际上并不属于您的业务对象，那么这清楚地表明您应该出于不同目的使用不同的对象

例如，您可能希望使用“ 模型视图”视图模型模式创建视图模型 。

但是，如果发现您的业务对象将由其他系统监视，并且需要通知它们何时更改，则INotifyPropertyChanged接口是合适的。 但是，在您的特定情况下，听起来并非如此。