在软件架构中在哪里实现 INotifyPropertyChanged 接口?
我目前正在创建一个我认为足够大的项目，以仔细分离其架构中的知名层.
I am at the moment creating a project large enough in my opinion to separate carefully the well-known layers in its architecture.
对于数据访问层 (DAL)，我只使用 .NET Entity Framework.
For the data access layer (DAL), I simply use the .NET Entity Framework.
对于业务层，我定义了业务对象，随后的开发人员可以使用这些对象来创建客户端和处理 UI.
For the business layer, I defined business objects which are then available to subsequent developers who can use them to create clients and handle the UI.
由于我还必须开发客户端应用程序以进行演示，因此我意识到拥有 ObservableCollection 而不是列表，并且对象应该尽可能多地实现 INotifyPropertyChanged 界面，以便 UI 自动检测更改并显示更新直接.
As I have to develop a client application as well for demonstration purpose, I realized that it can be very helpful to have an ObservableCollection<T> instead of a list, and that as often as possible the objects should implement the INotifyPropertyChanged interface so that the UI automatically detects the changes and displays the updates straightaway.
然而，我想知道从架构的角度来看这是否真的是正确的方法.也就是说，技术上，我不认为业务层应该与 UI 显示有任何关系，因为我们并不真正知道"程序员可能会使用它做什么；例如，他可能只想将对象用于计算目的.因此，我想知道通常的做法是什么?
Yet, I wonder whether it is really the right way to do from a architectural point of view. That is, technically, I don't think the business layer should have anything to do with UI display as we do not really "know" what a programmer might use it for; he might just want to use the objects for computational purposes for example. Hence, I was wondering what was the common practice?
我是否应该在业务层实现这些功能(不会有性能问题)?我应该在包含所有这些功能的另一层中创建某种装饰器"对象吗?
Should I implement these features in the business layer (there would be no performance issue)? Should I create some kind of "decorator" object in another layer which includes all these features?
正如 Skliwz 在评论中提到的，放置它的正确位置是在专门绑定到 UI 层的对象中.
As mentioned by Skliwz in the comments, the correct place to place this is in objects that are specifically bound to the UI layer.
如果您将业务对象直接绑定到 UI 层，并且您发现 INotifyPropertyChanged 接口并不真正属于您的业务对象，那么它清楚地表明您应该为不同的目的使用不同的对象
If you are binding your business objects directly to the UI layer, and you find that the INotifyPropertyChanged interface doesn't really belong on your business objects, then it's a clear indicator that you should have different objects for different purposes
例如，您可能想要一个视图模型，使用 Model View View Model 模式.
For example, you might want to have a view model, using the Model View View Model pattern.
但是，如果您发现您的业务对象要被其他系统监控，并且您需要关于它们何时更改的通知，那么 INotifyPropertyChanged 接口是合适的.但是，听起来在您的具体情况下，事实并非如此.
However, if you find that your business objects are to be monitored by other systems, and you need notifications as to when they changed, then the INotifyPropertyChanged interface is appropriate. However, it sounds like in your specific case, it is not.