摘记[理论]原创翻译：基于MVVM设计模式的WPF应用程序

原帖：http://www.cnblogs.com/starsoul/archive/2011/07/04/2097002.html

概述：

开发一个专业的应用程序软件的用户界面不容易。它可能涉及到数据融合，交互设计，可视化设计，连接，多线程，安全，国际化，验证，单元测试和可触摸技术。

有流行的设计模式，可以帮助驯服这个难使用的野兽，但是正确的区分和选择多个关注可能是困难的。模式越复杂，越有可能捷径在以后被使用，破坏了以前正确方式做事情的努力。

我们将清楚数据模板，命令，数据绑定，资源系统和MVVM模式如何结合在一起，创建一个简单地，可测试的，强大的框架，在此框架上任何WPF程序都能存活。

演变：
MVP是Model-View-Controller模式的变种

你在屏幕上看到的是View，它所显示的数据是Model，而Presenter 把这两者连接在一起。View依赖Presenter去组装数据，和用户输入进行交互，提供输入验证(可能通过委托的模型)，以及一些其他的任务。

PM模式相似于MVP，它分离出来view的行为和状态。PM模式的有趣的部分在于一个view的抽象被创建，叫做Presentation Model。View仅仅变成一个Presentation Model的一个表现。
同步的逻辑作为代码存在于Presnetation Model类里。

MVVM与Fowler的Presentation Model相同，这两个模式都有一个View的抽象，其中包含了View的状态和行为。Fowler引入Presentation Model作为一种与UI平台无关的View的抽象的创建，而Gossman引入MVVM作为一种利用WPF的核心特征去简化用户界面的创建的标准化的方式。在这个意义上，我考虑MVVM是PM模式的更一般化，是为WPF和Silverlight平台而特制的。

当用户点击View上的一个button时，ViewModel上的一个command去执行一个请求的行为。ViewModel，而不是View，执行所有模型数据的修改。

View绑定到ViewModel的属性上，这反过来，公开了在model对象里包含的数据和其他的指定到view上一些其他状态。在View和ViewModel之间的绑定被很简单地构建，因为一个ViewModel对象被设置作为一个view的DataContext。如果在ViewModel里的属性值改变，那些新的值自动地通过数据绑定传播到view。当用户点击View上的一个button时，ViewModel上的一个command去执行一个请求的行为。ViewModel，而不是View，执行所有模型数据的修改。

View类不知道model类的存在，而ViewModel和Model都不知道view。实际上，Model完全地遗忘了ViewModel和View存在的事实。这是非常松耦合的设计，你很快就能看到这在很多方面的好处。

一些文章

更多的关于MVP的东西，我建议你阅读一下Jean-Paul Boodhoo's2006年8月份的设计模式专栏。August 2006 Design Patterns column.

早在2004年，Martin Fowler发表了一篇命名为Presentation Model(PM)的模式的文章Presentation Model 

在Glenn Block2008年9月发表的一篇优秀的文章”Prism: Patterns for Building Composite Applications with WPF"，他解释了微软WPF的组合应用程序指导。

更多的关于绑定和数据模板的知识在2008年7月的文章里，“ Data and WPF: Customize Data Display with Data Binding and WPF."。

如果你不熟悉命令，我推荐你阅读Brian Noye2008年9月发行的一篇综合性的文章“ Advanced WPF: Understanding Routed Events and Commands in WPF”

为什么WPF开发人员喜爱MVVM

WPF使得MVVM成为一个强大的模式的一个最重要的方面是数据绑定。通过一个view到Viewmodel的绑定属性，你在两者之间得到松耦合，完整地移除了在ViewModel里直接写代码更新一个view的需要。数据绑定系统也支持输入验证，提供了传递验证错误到view的标准方式。

WPF使得这个模式如此有用的其他两个特征是数据模板和资源系统。数据模板应用View到ViewModel对象显示在用户界面。你能在XAML里声明模板，让资源系统为你在运行时自动地加载和应用这些模板。

如果WPF不支持commands，MVVM模式不会如此强大。

因为ViewModel类容易做单元测试。当一个应用程序的交互逻辑位于一系列的ViewModel类时，你能很容易地写代码去测试它。在这个意义上，View和单元测试仅仅是两个不同类型的ViewModel的消费者。有一套测试程序为应用程序的ViewModel提供自由的测试，帮助减少维护应用程序的消耗 。
为了推广自动化回归测试的创建，ViewModel类得易测性可以帮助正确地设计容易换肤的用户界面。当你正在设计一个应用程序时，你能经常决定一些东西是应该在view里还是在viewmodel里，通过假想你想要写一个单元测试去消耗ViewModel。如果你能为Viewmodel写单元测试而没有创建任何UI对象，你也能完全地剥离ViewModel因为它不依赖于指定的可见元素。最终，对于视觉设计人员的开发者，使用MVVM使得创建一个平滑的设计者/开发者工作流很简单。由于一个view仅仅是一个ViewModel的任意的消费者，很容易把view剥离出来，换上一个新的view去。这个简单的步骤可以快速地开发原型和设计师开发出来的用户界面的评估。开发团队能集中精力在ViewModel类，设计团队能集中精力制作用户友好的视图。连接这两个团队的输出除了确保正确的绑定在视图的XAML文件中存在之外可能涉及更多。