我目前正在创建一个足够大的项目，以便仔细分离其架构中众所周知的层。
对于数据访问层（DAL），我只使用.NET实体框架。
对于业务层，我定义了业务对象，然后可供后续开发人员使用它们来创建客户端并处理UI。
由于我必须开发一个客户端应用程序以用于演示目的，我意识到拥有一个ObservableCollection<T>而不是一个列表是非常有帮助的，并且尽可能多的对象应该实现{ {3}}界面，以便UI自动检测更改并立即显示更新。
然而，我想知道从架构的角度来看它是否真的是正确的方法。也就是说，技术上，我不认为业务层应该与UI显示有任何关系，因为我们并不真正“知道”程序员可能会使用它的内容;例如，他可能只想将这些对象用于计算目的。因此，我想知道通常的做法是什么？
我应该在业务层中实现这些功能（不存在性能问题）吗？我应该在包含所有这些功能的另一层中创建某种“装饰器”对象吗？
答案 0 :(得分：1)
正如评论中Skliwz所提到的，放置它的正确位置是专门绑定到UI层的对象。
如果您将业务对象直接绑定到UI层，并且发现INotifyPropertyChanged接口并不真正属于您的业务对象，那么它是一个明确的指示器，您应该为不同的对象提供不同的对象目的
例如，您可能希望使用Model View View Model模式获得视图模型。
但是，如果您发现其他系统要监视您的业务对象，并且您需要通知它们何时更改，那么INotifyPropertyChanged接口是合适的。但是，这听起来像是在你的具体情况下，它不是。