在软件架构中在哪里实现 INotifyPropertyChanged 接口？答案

【问题标题】：Where to implement INotifyPropertyChanged interface in software architecture?在软件架构中在哪里实现 INotifyPropertyChanged 接口？
【发布时间】：2011-11-14 22:21:18
【问题描述】：

我目前正在创建一个足够大的项目，以仔细分离其架构中的知名层。

对于数据访问层 (DAL)，我只使用 .NET Entity Framework。

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

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

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

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

【问题讨论】：

每一层应该有不同的类集。听起来有点多余，但这是正确的选择（正如您的疑问所证明的那样）

标签： .net architecture

【解决方案1】：

正如 Skliwz 在 cmets 中提到的，放置它的正确位置是在专门绑定到 UI 层的对象中。

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

例如，您可能希望拥有一个使用Model View View Model 模式的视图模型。

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

【讨论】：

感谢 MVVM 链接，但是，我不确定您最后一段的意思。为什么INotifyPropertyChanged 不合适？
@SRKX：嗯，我不能肯定，但通常情况下，UI 元素由代理（WCF、RIA 等）提供，它会自动为您生成这些对象。这些不是您的业务对象，它们是表示。您通常需要诸如视图模型之类的东西来处理特定的 UI 交互（连接功能的按钮按下等）。但是，如果您在后端，并且您的模型在内存中，并且属性更改会发送一条消息说 MSMQ，那么您的对象实现 INotifyPropertyChanged 是有意义的。
@SRKX：但是，在您的情况下，您似乎想要绑定到 UI。我推荐一个封装业务对象的视图模型，可能实现INotifyPropertyChanged 本身，以及有助于将数据绑定到显示的任何附加属性。