要财产，还是不要财产？

Question

我想弄清楚什么会给我最好的代码。当然，我认为这有点主观。

我有一个应用程序访问我已经编写了一个程序集的数据库，该程序集隐藏了使用此程序集的所有应用程序中关于此数据库的详细信息。

我也有一个WPF应用程序，利用这个程序集来显示我想要使用数据绑定的各种成本计算。

数据绑定只可能对象的属性（据我开始工作）。这将意味着我需要一个对象，最好使用INotify支持和一系列对象。不过，我宁愿将INotify和WPF事物保存在处理数据库访问的程序集之外。

其他人如何解决这个问题：将WPF事情保存在数据库层之外（如INotify）并且在WPF中允许绑定？写一个包装？或者大多数人将'property'/'INotify'类作为数据传输对象直接放入数据库层？

Answer 1

你是一个误解下劳动。 INotifyPropertyChanged是不是是一个WPF的东西。试想一下：

1. 这是System.dll
2. 它是System.ComponentModel命名空间部分
3. 自版本它在.NET框架一直是部分2.0
4. 这是大多数NET Framework数据对象进行的支持该框包括ADO.NET的DataRowView和ComponentModel的ObservableCollection。
5. 它automaticaly使用的WinForms，ASP.NET，WPF，和许多第三方包与数据对象的接口。

由于所有自动生成的数据层微软生产的工具INotifyPropertyChanged，为什么你应该对待你的数据层有什么不同呢？显然你的数据层需要在属性改变时以某种方式通知它的客户。为什么不使用.NET Framework的内置机制？

在我看来任何包含可变对象的数据层都应该实现属性更改通知，理所当然。 INotifyPropertyChanged被设计成这样的通知机制，为什么不按照它的意图使用它？

更为一般的说明：添加额外的包装层通常只是低效率的代码膨胀。有时这是必要的，甚至是有益的，但不要仅仅为了这样做而做。作为视图模型，很多时候合理设计的数据层对象都可以很好地工作。只有在视图模型与数据层分离的地方或者需要额外功能的地方，您应该考虑引入额外的复杂性，然后才根据具体情况进行处理。

Answer 2

我认为最简洁的解决方案是在您的WPF程序集中编写一个包装对象，并将INotify类型保留在数据库程序集之外。没有理由将INotify的复杂性添加到数据库层，除非它提供了特定的优势。

Answer 3

其他人通过实施MVVM设计模式解决此问题。

Answer 4

写的包装。如果包装非常直接，你甚至可以建立一个发生器来生成所有基于源DTO的类

Answer 5

你可以看看PostSharp，这只是面向方面编程（AOP）的一种东西。有很多examples将INotify *编织成模型类。我还没有开始在一个真正的项目上使用PostSharp，但在我们尝试过的一些测试场景中，它看起来很有前景。

Answer 6

还有一点要注意，是非常有用的 - 如果你知道你要绑定的属性是不变的（即一个单独的对象或东西，会被初始化一次并没有碰过），你不需要使它INotifyPropertyChanged - 一个简单的属性将正常工作。