有什么反对让所有域对象都从 INotifyPropertyChanged 继承的吗？答案

【问题标题】：Does anything speak against making all domain objects inherit from INotifyPropertyChanged?有什么反对让所有域对象都从 INotifyPropertyChanged 继承的吗？
【发布时间】：2014-08-31 12:31:38
【问题描述】：

我正在重构和重新设计在某种程度上使用MVVM 的应用程序的域对象。有什么反对让所有域对象 (POCOs) 都继承自 INotifyPropertyChanged，因此任何人都可以随意观察对象。

结合https://stackoverflow.com/a/1316566/448357，这甚至不必非常难看。

另一方面，polluting my domain object 包含可能根本不需要的东西，因为无论如何都会有一个单独的 View-Model 怎么办？ Margabit 指出：UI 模型！= 域模型

【问题讨论】：

你知道什么是污染吗？拥有您经常需要来回切换的域/UI 模型。这个我看过，不好看创建一个实现 INPC 的基类和其他任何对您的模型方便的东西都没有错。你的肚脐，它不需要你那么盯着它。继续前进。

标签： c# mvvm architecture inotifypropertychanged domain-object

【解决方案1】：

IMO，域对象不应实现 INotifyPropertyChanged。应该实施它的是您的 ViewModel。

原因是：

您可能主要需要在包含 POCO 的视图模型中引发 PropertyChanged 事件
您只需实施一次。
如果您的 POCO 想要引发事件并通知其中发生了某些事情，我不确定 PropertyChanged 是否会引发最有意义的事件。

【讨论】：

【解决方案2】：

我认为这在一定程度上取决于项目的范围：如果这是一个小型项目，其中 Domainmodels 也用作 UI-mmodels，如果您愿意，请务必这样做。

但如果您经常需要 UI 模型，例如因为有很多属性/方法不属于您的域模型，所以不要打扰 - 您几乎没有或没有任何理由造成开销。

什么时候需要 UI 模型？我的经验法则：如果您要引入具有 [NotMapped]（实体框架）属性的属性，请继续使用此属性制作 UI 模型。

此外，如果该项目的某些部分有可能在另一个上下文中使用（Web 应用程序、电话等 pp），我建议不要这样做 - 无论如何你都需要 UI 模型。

【讨论】：

【解决方案3】：

为避免在您的类中插入代码，您可以创建一个透明代理。你可以使用城堡 http://www.castleproject.org/dynamicproxy/index.html

唯一的限制是您必须通过工厂创建类的实例。

您也可以使用 System.Runtime.Remoting.Proxies.RealProxy 类，但您的基类必须派生自 MarshalByRef（仍然是 POCO？:)）。

http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=IT-IT&k=k(SYSTEM.RUNTIME.REMOTING.PROXIES.REALPROXY)%3bk(TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION%3dV4.0%22)%3bk(DevLang-CSHARP)&rd=true

【讨论】：