我认为DependencyProperty和INotifyPropertyChanged在绑定中用于两种不同的事情:第一个用于使一个属性成为绑定的目标并接收来自另一个属性的输入(使用{Binding…}来设置属性)，当你想要一个属性的值被用作绑定的源(绑定路径表达式中的名称)时，最后一个。 所以选择仅仅是技术上的。

选择DependencyObject的原因只有一个——绑定会工作得更好。只是尝试一个ListBox和TextBox的例子，用INotifyPropertyChanged属性与DependencyProperty的数据填充列表，并从TextBox编辑当前项目…

Kent写了一篇关于这个主题的有趣博客:视图模型:POCOs与依赖对象。

简短的总结:

DependencyObjects没有被标记为 可序列化的 DependencyObject类重写并密封Equals()和 GetHashCode方法()方法 DependencyObject具有线程相关性——它只能被访问 就在那根线上 创建

我更喜欢POCO方法。PresentationModel(又名ViewModel)实现INotifyPropertyChanged接口的基类可以在这里找到:http://compositeextensions.codeplex.com

最近我也不得不考虑这个决定。

我发现INotifyPropertyChanged机制更适合我的需求，因为它允许我将GUI粘到现有的业务逻辑框架上，而不需要复制状态。我使用的框架有自己的观察者模式，很容易将一个级别的通知转发到下一个级别。我有一个简单的类，它实现了来自业务逻辑框架的观察者接口和INotifyPropertyChanged接口。

使用DP，您不能自己定义存储状态的后端。我将不得不让。net缓存我所绑定的每个状态项的副本。这似乎是一个不必要的开销-我的状态是大而复杂的。

因此，在这里我发现INotifyPropertyChanged更适合将属性从业务逻辑公开到GUI。

也就是说，我需要一个自定义GUI小部件来公开一个属性，并对该属性进行更改以影响其他GUI小部件DP证明了简单的解决方案。

所以我发现DP对于GUI到GUI的通知很有用。

把ViewModel依赖项交给WPF真的是个好主意吗?

. net 4.0将有System.Xaml.dll，所以你不必依赖于任意的框架来利用它。请参阅Rob Relyea关于他的PDC会议的帖子。

我的看法

XAML是一种描述对象的语言，而WPF是一种框架，其描述对象是UI元素。

它们的关系类似于c#(一种描述逻辑的语言)和。net(一种实现特定类型逻辑的框架)。

XAML的目的是声明性的对象图。W*F技术是这种范例的很好的候选者，但是XAML独立于它们而存在。

XAML和整个依赖系统是作为WF和WPF的独立堆栈实现的，可能是为了利用不同团队的经验，而不会在它们之间创建依赖关系(没有双关语)。

根据WPF性能指南，DependencyObjects肯定比实现INotifyPropertyChanged的POCOs性能更好:

http://msdn.microsoft.com/en-us/library/bb613546.aspx