C# 财产，还是不财产？

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

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

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

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

---

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

我认为最干净的解决方案是在WPF程序集中编写一个包装器对象，并将

INotify

类型保留在数据库程序集中。没有理由将INotify的复杂性添加到数据库层，除非它提供了特定的优势。

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

编写一个包装器。如果包装非常简单，您甚至可以构建一个生成器，根据源DTO生成所有类，这正是面向方面编程（AOP）的目的。有很多将INotify*编织到模型类中。我还没有开始在真正的项目上使用PostSharp，但在我们尝试过的一些测试场景中，它看起来很有希望。

还有一件事需要注意，这很有用-如果您知道绑定到的属性是不可变的（即单例对象或只初始化一次且从不触及的对象），您不需要将其设置为INotifyPropertyChanged—一个简单的属性就可以了。

您是在误解下工作的

INotifyPropertyChanged

不是WPF的东西。考虑：

它是

System.dll的一部分

它位于

System.ComponentModel

命名空间中

自版本2.0以来，它一直是in-NET Framework的一部分

大多数NET Framework数据对象都支持它，包括ADO.NET的

DataRowView

和ComponentModel的

ObservableCollection

WinForms、ASP.NET、WPF和许多第三方软件包自动使用它与数据对象进行接口

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

在我看来，任何包含可变对象的数据层都应该实现属性更改通知，这是理所当然的

INotifyPropertyChanged

被设计成这样一种通知机制，那么为什么不按原意使用它呢

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