当在一个模型-视图-视图模型架构的WPF应用程序中实现ViewModel时,似乎有两个主要的选择:如何使它可数据化。我已经看到实现使用DependencyProperty属性的视图要绑定,我已经看到ViewModel实现INotifyPropertyChanged代替。
我的问题是,什么时候我应该更喜欢其中一个?有什么性能差异吗?把ViewModel依赖项交给WPF真的是个好主意吗?在做设计决定时,我还需要考虑什么?
当在一个模型-视图-视图模型架构的WPF应用程序中实现ViewModel时,似乎有两个主要的选择:如何使它可数据化。我已经看到实现使用DependencyProperty属性的视图要绑定,我已经看到ViewModel实现INotifyPropertyChanged代替。
我的问题是,什么时候我应该更喜欢其中一个?有什么性能差异吗?把ViewModel依赖项交给WPF真的是个好主意吗?在做设计决定时,我还需要考虑什么?
当前回答
依赖属性是自定义控件创建的粘合剂。如果你想在XAML设计时使用Intelli-sense在属性窗口中显示你的属性,你必须使用Dependency属性。INPC在设计时永远不会在属性窗口中显示属性。
其他回答
选择完全取决于您的业务逻辑和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。该链接有很多参考模型-视图-视图模型模式,这与本文的讨论非常相关。
把ViewModel依赖项交给WPF真的是个好主意吗?
. net 4.0将有System.Xaml.dll,所以你不必依赖于任意的框架来利用它。请参阅Rob Relyea关于他的PDC会议的帖子。
我的看法
XAML是一种描述对象的语言,而WPF是一种框架,其描述对象是UI元素。
它们的关系类似于c#(一种描述逻辑的语言)和。net(一种实现特定类型逻辑的框架)。
XAML的目的是声明性的对象图。W*F技术是这种范例的很好的候选者,但是XAML独立于它们而存在。
XAML和整个依赖系统是作为WF和WPF的独立堆栈实现的,可能是为了利用不同团队的经验,而不会在它们之间创建依赖关系(没有双关语)。
依赖属性是自定义控件创建的粘合剂。如果你想在XAML设计时使用Intelli-sense在属性窗口中显示你的属性,你必须使用Dependency属性。INPC在设计时永远不会在属性窗口中显示属性。
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的一个很好的例子。