在哪里实现软件架构INotifyPropertyChanged接口？ [英] Where to implement INotifyPropertyChanged interface in software architecture?

问题描述

我在此刻创建项目在我看来，要仔细分离知名层在其结构足够大。

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实体框架。

For the data access layer (DAL), I simply use the .NET Entity Framework.

有关业务层，我定义这将可用于后续的开发谁可以使用它们来创建客户端和处理用户界面业务对象。

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＆LT; T＆GT; >而不是一个列表，并且尽可能多的对象应该实施的 INotifyPropertyChanged的 接口从而使用户界面自动检测的变化，并显示更新通俗易懂

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?

推荐答案

由于在评论中提到 Sk​​liwz 中，将这一正确的位置是在被特异性结合到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

例如，您可能希望有一个视图模型，使用模型视图视图模型格局。

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.

这篇关于在哪里实现软件架构INotifyPropertyChanged接口？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！