财产，还是不财产？答案

【问题标题】：To property, or not to property?财产，还是不财产？
【发布时间】：2010-01-25 16:14:24
【问题描述】：

我试图找出什么会给我最好的代码。当然，这有点主观，我意识到。

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

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

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

其他人如何解决这个问题：将 WPF 的东西保持在数据库层之外（例如 INotify），而在 WPF 内部允许绑定？写一个包装？还是大多数人都会把一个'property'/'INotify'类作为数据传输对象直接放到数据库层？

【问题讨论】：

标签： c# wpf dns

【解决方案1】：

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

【讨论】：

【解决方案2】：

你在一个误解下工作。 INotifyPropertyChanged 不是 WPF 的东西。考虑：

是System.dll的一部分
它位于System.ComponentModel 命名空间中
从 2.0 版开始，它就成为 NET Framework 的一部分
大多数 NET Framework 数据对象都支持它，包括 ADO.NET 的 DataRowView 和 ComponentModel 的 ObservableCollection。
WinForms、ASP.NET、WPF 和许多第三方包自动使用它来连接数据对象。

既然微软生产的所有自动生成的数据层都实现了INotifyPropertyChanged，那么为什么要以不同的方式对待数据层呢？显然，当属性发生变化时，您的数据层需要以某种方式通知其客户端。为什么不使用 NET Framework 的内置机制？

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

一般来说：添加额外的包装层通常只是低效的代码膨胀。有时它是必要的，甚至是有益的，但不要仅仅为了做它而做。很多时候，合理设计的数据层对象作为视图模型工作得很好。只有在您的视图模型与您的数据层不同或您需要额外功能的地方，您才应该考虑引入额外的复杂性，并且只能根据具体情况而定。

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

您可能会查看PostSharp，这正是面向方面编程 (AOP) 的用途。有很多 examples 将 INotify* 编织到模型类中。我还没有开始在实际项目中使用 PostSharp，但在我们尝试过的一些测试场景中它看起来很有希望。

【讨论】：

【解决方案6】：

还有一点很有用 - 如果您知道要绑定的属性是不可变的（即，单例对象或将被初始化一次并且永远不会触及的东西），您不要需要将其设置为 INotifyPropertyChanged - 一个简单的属性就可以正常工作。

【讨论】：