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

选择完全取决于您的业务逻辑和UI抽象级别。如果你不想好好分开，那么DP可以帮你。

DependencyProperties将主要适用于VisualElements级别，所以如果我们为每个业务需求创建大量的dp并不是一个好主意。DP的开销也比INotifyPropertyChanged大。当你设计WPF/Silverlight时，试着把UI和ViewModel完全分开，这样我们就可以随时改变布局和UI控件(基于主题和样式)。

请参考这篇文章- https://stackoverflow.com/questions/275098/what-applications-could-i-study-to-understand-datamodel-view-viewmodel。该链接有很多参考模型-视图-视图模型模式，这与本文的讨论非常相关。

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

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

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

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

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

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

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

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

简短的总结:

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

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

看起来依赖属性应该用在你创建的控件中，比如按钮。要在XAML中使用属性并使用所有WPF特性，这些属性必须具有依赖属性。

然而，你的ViewModel最好使用INotifyPropertyChanged。使用INotifyPropertyChanged可以让你在需要的时候拥有getter/setter逻辑。

我建议查看Josh Smith的基类版本，它已经实现了INotifyPropertyChanged:

http://joshsmithonwpf.wordpress.com/2007/08/29/a-base-class-which-implements-inotifypropertychanged/

我认为这是如何创建ViewModel的一个很好的例子。