MVVM模式构建WPF.docx

MVVM模式构建WPF.docx

《MVVM模式构建WPF.docx》由会员分享，可在线阅读，更多相关《MVVM模式构建WPF.docx（33页珍藏版）》请在冰点文库上搜索。

MVVM模式构建WPF

使用MVVM设计模式构建WPF应用程序

本文是翻译大牛JoshSmith的文章，WPFAppsWithTheModel-View-ViewModelDesignPattern，译者水平有限，如有什么问题请看原文，或者与译者讨论（非常乐意与你讨论）。

本文讨论的内容：

WPF与设计模式

MVP模式

对WPF来说为什么MVVM是更好的选择

用MVVM构建WPF程序

本文涉及的技术：

WPF、数据绑定

内容列表

有序与混乱

模型-视图-视图模型的演变

为什么WPF开发者喜欢MVVM

演示程序

中继命令逻辑

ViewModel类层级结构

ViewModelBase类

CommandViewModel类

MainWindowViewModel类

View对应ViewModel

数据模型和Repository

新增客户数据表单

所有客户视图

总结

开发UI，对一个专业软件并不容易。

它需要未知数据、交互式设计，可视化设计、联通性，多线程、国际化、验证、单元测试以及其他的一些东西才能完成。

考虑到UI要展示开发的系统并且必须满足用户对系统风格不可预知的变更，因此它是很多应用程序最脆弱的地方。

有很多的设计模式可以帮助解决UI不断变更这头难缠的野兽，但是恰当的分离和描述多个关注点可能很困难。

模式越复杂，之后用到的捷径越可能破坏之前正确的努力。

这并不总是设计模式的错。

有时使用要写很多的代码复杂设计模式，这是因为我们使用的UI平台并不适合简单是设计模式。

UI平台需要做的是很容易使用简单的，久经考验的，开发者认识的设计模式构建UI。

庆幸的是，WPF就是这样一个平台。

随着是使用WPF开发的比例不断升高，WPF社区发展了自己的模式与实践生态圈子。

在本文，我将讨论一些设计与实现客户端应用程序的WPF最佳实践。

利用WPF和MVVM设计模式衔接的一些核心功能，我将通过一个例子介绍，用“正确”的方式构建一个WPF程序是多么的简单。

datatemplates,commands,databinding,theresourcesystem以及MVVM模式怎么揉合到一起创建一个简单的、可测试的、健壮的框架，并且任何WPF程序都能使用，到文章最后，这一切都很清晰明了。

文中的例程可以作为现实中一个WPF应用程序的模版，并且使用MVVM设计模式作为其核心架构。

例程解决方案中的单元测试部分，展示了测试ViewModel类的功能是很容易的。

在深入本文之前，我们首先看一下我们要使用像MVVM这样的设计模式。

有序与混乱

没有必要在一个”Hello,World!

”的程序中使用设计模式。

任何一个合格的开发者看一眼就指导那几行代码是干什么的。

然而随着程序功能点的增加，随之代码的数量以及移动部件也会增多。

最终系统的复杂度以及不断出现问题，促使开发者组织他们的代码，以便它们更容易理解，讨论、扩展以及维护。

我们通过给代码中某些实体命以众所周知的名字，减少复杂系统认知误区。

我们给函数块命名主要依据系统中的功能角色。

开发者有意识的根据设计模式组织他们的代码，而不是根据设计模式自动去组织。

无论哪一种，都没有什么问题。

但是在本文中，我说明在WPF程序中明确使用MVVM模式的好处。

某些类的名称，包括MVVM模式中著名的术语，如果类是view的抽象类就以ViewModel结束。

这种方式有助于避免之前提到的认知误区。

相反，你也可以让那种受控的误区存在，这正是大部分软件开发项目的自热状态。

模型-视图-视图模型的演变

自从人们开始构建UI时，就有很多流行的设计模式让UI构建更容易。

比如，MVP模式在各种UI编程平台中都非常流行。

MVP是MVC模式的一种变体，MVC模式已经流行了几十年了。

以防你之前从没用过MVP模式，这里做一个简单的解释。

你在屏幕上看到的是View，它显示的数据是Model，Presenter就是把两者联系起来。

View依赖Presenter并通过Presenter展示Model数据，响应用户输入，提供数据验证（或许委托给Model去完成）以及其他的一些任务。

如果你想了解更过关于MVP模式，我建议你去读Jean-PaulBoodhoo的August2006DesignPatternscolumn。

2004年晚些时候，MartinFowler发表了一篇叫PresentationModel（PM）的模式。

PM模式和MVP类似，MVP是把一个View从行为和状态分离出来。

PM中令人关注的部分是创建view的抽象，叫做PresentationModel。

之后，View就仅仅是PresentationModel的展示了。

在Fowler的论文中，他展示了PresentationModel经常更新View，以便两个彼此同步。

同步逻辑组作为代码存在于PresentationModel类中。

2005年，JohnGossman，目前是微软WPF和Silverlight架构师，在他的博客上披露了Model-View-ViewModel（MVVM）模式。

MVVM和Fowler的PresentationModel是一致的，两个模式的特征都是View的抽象，都包含了View的行为和状态。

Fowler引入PresentationModel是作为创建独立平台的View的抽象，而Gossman引入MVVM是作为标准化的方法，利用WPF的核心特点去简化UI的创建。

从这种意义上来讲，我把MVVM作为一般PM模式的一个特例。

在GlennBlock一遍优秀的文章"Prism:

PatternsforBuildingCompositeApplicationswithWPF"，于2008年9月微软大会发布，他解释了WPF微软组合程序开发向导。

术语ViewModel没有用到，然而PM却用来描述View的抽象。

这篇文章自始至终，都没没有出现我要将MVVM模式，以及View的抽象ViewModel。

我发现这个术语在WPF和Silverlight社区中比较流行。

不像MVP中的Presenter，ViewModel不需要引用View。

View绑定ViewModel的属性，ViewMode向Viewl暴露Model对象的数据以及其他的状态。

View和ViewModel之间的绑定很容易构造，因为ViewModel对象可以设置为View的DataContext。

如果ViewModel中的属性值发生改变，新值将通过绑定自动传送给View。

当用户点击View中的按钮时，ViewMode对于的Command将执行请求的动作。

ViewModel，绝不是View，去执行实体对象的修改。

View类并不知道Model类是否存在，同时ViewModel和Model也不知道View。

实际上,，Model完全不知道ViewModel和View存在，这是一个非常松耦合的设计，在很多方面都有好处，这不就你就会看到。

为什么WPF开发者喜欢MVVM

一旦开发者适应了WPF和MVVM，就很难区别两者。

因为MVVM非常适合WPF平台，并且WPF被设计使用MVVM模式更容易构建应用程序，MVVM就成了WPF开发者的通用语。

事实上，微软内部正在用MVVM开发WPF应用程序，像MicrosoftExpressionBlend，然而当时WPF平台的核心功能依然在开发之中。

WPF的很多方面，像控制模型以及数据模版，都利用了MVVM推荐的显示状态和行为分离技术。

MVVM之所以成为一个伟大设计模式，是因为WPF的一个最重要的特征数据绑定构造。

通过把Viewde属性绑定到ViewModel，你就可以得到两者松耦合的设计，并且完全去除ViewModel更新View的那部分代码。

数据绑定系统支持输入验证，并且输入验证提供了传递错误给View的标准方法。

另两个WPF的特点，数据模版和资源系统让MVVM模式更加可用。

数据模版把View应用在ViewModel对象上，以便其能够在UI上显示。

你可以在Xaml中声明模版，让资源系统在系统运行过程中自动定位并应用这些模版。

你可以从我2008年7月写的一篇文章,"DataandWPF:

CustomizeDataDisplaywithDataBindingandWPF."，获取更多关于绑定和数据模版的信息。

要不是WPF对Command的支持，MVVM模式就不会那么强大。

本文中，我会为你展示ViewModel怎样把Commands暴露给View，并且让View消费它的功能。

如果你对Command不是很熟悉，我推荐你读一下2008年9月BrianNoyes发布的文章，"AdvancedWPF:

UnderstandingRoutedEventsandCommandsinWPF"。

除了WPF（Silverlight2）本身让MVVM以一种自然的方式去构建程序之外，造成MVVM模式流行还有一个原因，那就是ViewModel类很容易进行单元测试。

从某种意义来讲，View和单元测试只是ViewModel两个不同类型的消费者。

拥有一套应用程序的单元测试，可以为提供更自由、快速的回归测试，而回归测试有助于降低之后应用的维护成本。

除了促进创建自动化回归测试外，ViewModel类的可测试性也有助于设计更容易分离的UI。

当你设计应用时，你可以通过想象某些东西是否要创建单元测试消费ViewModel，来确定它们是放到View里面还是ViewModel里面。

如果你可以为ViewModel写单元测试而不用创建任何UI控件，你也可以把ViewModel剥离出来，因为它不依赖任何具体可视化的组件。

最后，对于要和设计者合作的开发者来说，使用MVVM模式使得创建平滑的开发/设计工作流更加容易。

既然View可以是ViewModel的任意一个消费者，就很容易去掉一个View通过新增一个View去渲染ViewModel。

这个简单的步骤允许设计师构建快速原型以及评估UI设计。

这样开发团队可以关注创建健壮的ViewModel类，而设计团队可以关注设计界面友好的View。

要融合两个团队输出只需要在View的xaml上进行正确的绑定即可。

演示程序

到此为止，我们回顾了MVVM的历史以及具体操作理论。

我也说明了它在WPF开发者中间如此流行的原因。

现在是时候继续我们的步伐，看一下MVVM模式在实际中的应用。

这篇文章中的演示程序以各种方式使用MVVM设计模式，它提供了丰富的例子，帮助在上下文中理解MVVM的概念。

我用VS2008SP1创建的这个演示程序，框架是Microsoft.NETFramework3.5SP1。

单元测试是用的VisualStudiounittesting。

应用可以包含任意数量的“Workspace”，每一个都可以由用户点击左侧导航区的命令链接打开。

所有的Workspace寄宿在主区域TabControl中，用户可以通过点击workspace的tabitem上关闭按钮关闭workspace。

应用程序有两个可用的workspace：

"AllCustomers"和"NewCustomer"。

运行程序，打开一些workspace，UI看起来如图1所示。

图1Workspaces

一次只有一个“AllCustomers“Workspace的实例可以打开，但是可以打开多个NewCustomerWorkspace。

当用户决定创建一个新的客户时，她必须填完图2所示的数据输入表单。

图2新客户数据输入表单

填完数据输入表单的所有有效值点击“Save”按钮，新客户的名称将会出现在tabitem上面，同时新客户也会增加到客户列表中。

应用程序不支持删除或者编辑客户，但是这和其它功能类似，很容易在已有的程序架构上去实现。

现在你已经对演示程序有了更深层次的理解了，接下来我们研究它是如何设计以及实现的。

中继命令逻辑（RelayingCommandLogic）

除了类构造器里调用初始化组件标准的样板代码，应用中的每一View的codebehind文件都是空的。

实际上你可以移除View的codebehind文件，程序让人能够争正确的编译和运行。

尽管View中没有事件处理方法，但是当用户点击按钮时，程序依然能够响应并满足用户的请求。

之所以这样，是因为UI上Hyperlink、Button以及MenuItem控件的Command属性被绑定了。

绑定机制确保当用户在控件上点击时，由ViewModel暴露的ICommand对象能够执行。

你可以把command对象看作一个适配器，这个适配器让command对象很容易消费在View中声明的ViewModel功能。

当ViewModel暴露ICommad类型的实例属性，被暴露的Command对象使用ViewModel中的对象去完成它的工作。

其中一个可能的实现模式是在ViewModel内创建一个私有嵌套类，以便command能够访问包含在ViewModel中的私有成员，而不至于污染命名空间。

嵌套类实现了ICommand接口，包含在ViewModel中对象的引用注入到其构造器中。

但是为ViewModel暴露的每个Command创建实现ICommad的嵌套类，会增加ViewModel类的大小。

更多的代码意味着存在BUGS潜力更大。

在演示程序中，RelayCommand类解决了这个问题。

RelayCommand允许通过把委托传给其构造器，以实现对命令逻辑的注入。

这种方式允许在ViewMode类中可以简单明了的实现Command。

RelayCommand是DelegateCommand的一个简单的变体，DelegateCommand可以在MicrosoftCompositeApplicationLibrary找到。

RelayCommand类代码如图3所示。

图3RelayCommand类

publicclassRelayCommand:

ICommand

{

#regionFields

readonlyAction