财产，还是财产？

Question

我想知道什么会给我最好的代码。我意识到，这当然有点主观。

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

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

数据绑定只能用于对象的属性（就我开始工作而言）。这意味着我需要一个对象，最好是INotify支持和一系列对象。但是，我更希望在处理数据库访问的程序集之外保留INotify和WPF。

其他人如何解决这个问题：将WPF内容保留在数据库层之外（例如INotify）和WPF允许绑定内部？写一个包装？或者大多数人将“属性”/“INotify”类作为数据传输对象直接放入数据库层？

Answer 1

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

Answer 2

你在误解中工作。 INotifyPropertyChanged 不是WPF的事情。考虑：

1. 它是System.dll
的一部分
2. 它位于System.ComponentModel命名空间
中
3. 自2.0版以来，它已成为.NET Framework的一部分
4. 大多数.NET Framework数据对象都支持它，包括ADO.NET的DataRowView和ComponentModel的ObservableCollection。
5. 它由WinForms，ASP.NET，WPF和许多第三方软件包自动使用，用于连接数据对象。

由于Microsoft自动生成的所有数据层都生成了工具INotifyPropertyChanged，为什么要以不同的方式处理数据层？显然，当属性发生变化时，您的数据层需要以某种方式通知其客户端。为什么不使用.NET Framework的内置机制？

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

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

Answer 3

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

Answer 4

写一个包装器。如果包装非常简单，您甚至可以构建一个生成器来生成基于源DTO的所有类

Answer 5

你可能会研究PostSharp，这就是面向方面编程（AOP）的用途。有许多examples将INotify *编织到模型类中。我还没有开始在一个真实的项目中使用PostSharp，但是在我们试过的一些测试场景中看起来很有希望。

Answer 6

还有一件事需要注意，这很有用 - 如果你知道你绑定的属性是不可变的（即单个对象或者某些东西会被初始化一次并且从未触及过），你不< / em>需要使它成为INotifyPropertyChanged - 一个简单的属性将正常工作。