基于MVVM设计模式的WPF应用程序.doc

/starsoul/archive/2011/07/04/2097002.html 原创翻译：基于MVVM设计模式的WPF应用程序 Posted on 2011-07-04 00:11 StarSoul 阅读(43) 评论(0) 编辑 收藏 第一次翻译英文技术文档，翻译不正确的地方请多多指正。原文及文中演示程序的地址：/en-us/magazine/dd419663.aspx 开发一个专业的应用程序软件的用户界面不容易。它可能涉及到数据融合，交互设计，可视化设计，连接，多线程，安全，国际化，验证，单元测试和可触摸技术。考虑到用户界面暴露了底层系统，必须满足其用户的不可预知的要求，它可以是许多应用中最不稳定的区域。有流行的设计模式，可以帮助驯服这个难使用的野兽，但是正确的区分和选择多个关注可能是困难的。模式越复杂，越有可能捷径在以后被使用，破坏了以前正确方式做事情的努力。 这不总是设计模式的问题。有时我们用复杂的设计模式，需要写很多的代码因为使用的UI平台不能帮助它用一个简单的模式。幸运地是，WPF提供了这一帮助。 由于软件界采用WPF的比率不断增长，WPF团体一直在开发它自己的模式生态系统和实践。在这篇文章中，我将查阅那些用WPF设计和实现的最好实践中的一些。通过利用一些结合MVVM设计模式的WPF的核心特征，我将介绍一个实例程序，演示以”正确方式”构建一个WPF程序是多么简单。 在 这篇文章的结尾， 我们将清楚数据模板，命令，数据绑定，资源系统和MVVM模式如何结合在一起，创建一个简单地，可测试的，强大的框架，在此框架上任何WPF程序都能存活。伴随着这篇文章的演示程序能作为一个真正的WPF程序的模板，用MVVM作为它的核心架构。在演示解决方案的单元测试显示了如何轻松地测试应用程序的用户界面功能，该功能在一系列的ViewModel类中存在。在进入细节之前，让我们首先回顾一下为什么要用MVVM这样的模式。 有序vs混乱 在一个简单的”Hello,World!”程序里使用设计模式是没有必要的，只会适得其反。任何一个合格的开发人员能一目了然的理解几行代码。然而，当程序的功能增加时，代码行和移动部件的数量相应地也会增加。最终，系统的复杂性，以及它包含的重复出现的问题，促使开发人员去重构他们的代码，以便它们更容易理解，讨论，扩展和解决问题。我们通过在源代码中对于某些实体应用众所周知的名称来减少认知上的混乱。我们通过考虑它在系统中的功能角色，确定一段代码中的名称。 开发者经常根据一个设计模式刻意地构建他们的代码，而不是让模式自然地出现。这两种方法都没有错，但是在这篇文章里，我考察了在一个WPF应用程序中明确地使用MVVM作为架构的好处。某些类的名称包含了MVVM模式中熟悉的术语，例如如果这个类是一个view的抽象，类名称以”ViewModel”结尾。这种方法有助于避免前面提到的认知混乱。你能很愉快地存在于一个混沌的控制，这是在最专业的软件开发工程中事务最自然的状态。 Model-View-ViewModel的革命 从人们开始创建软件用户界面开始，已经有流行的设计模式帮助使它更容易。例如，MVP模式已经在各种UI编程平台享有声望。MVP是Model-View-Controller模式的变种，这十多年来一直使用很广泛。万一你以前从来没有用过MVP模式，这里有一个简单的解释。你在屏幕上看到的是View，它所显示的数据是Model，而Presenter 把这两者连接在一起。View依赖Presenter去组装数据，和用户输入进行交互，提供输入验证(可能通过委托的模型)，以及一些其他的任务。如果你想要学习更多的关于MVP的东西，我建议你阅读一下Jean-Paul Boodhoos2006年8月份的设计模式专栏。 早在2004年，Martin Fowler发表了一篇命名为Presentation Model(PM)的模式的文章。PM模式相似于MVP，它分离出来view的行为和状态。PM模式的有趣的部分在于一个view的抽象被创建，叫做Presentation Model。View仅仅变成一个Presentation Model的一个表现。在Fowler的解释里，他显示了Presentation Model频繁地更新它的View，以便这两者之间保持一致。同步的逻辑作为代码存在于Presnetation Model类里。在2005年，John Gossman，当前微软WPF和Silverlight的架构师之一，在他的blog里发表了Model-View-ViewModel(MVVM)模式。MVVM与Fowler的Presentation Model相同，这两个模式都有一个View的抽象，其中包含了View的状态和行为。Fowler引入Presenta