BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

MVVM启示录

| 作者 李永伦 关注 0 他的粉丝 发布于 2012年4月4日. 估计阅读时间: 13 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

细究MVVM

熟悉WPF或Silverlight的同学应该不会对MVVM模式感到陌生了,它把应用程序划分成视图、视图模型和模型三层,如图1所示:

图 1

表面上,这个层次结构还蛮清楚的,但如果你细究每层应该包含什么,事情就没那么简单了。

视图应该是最容易理解的一个部分了,它通常是指用户可以看到的界面,一般都是通过XAML代码来实现的。但是,XAML代码并不能实现一切想要的效果,这个时候很多人会把目光投向代码隐藏文件,在里面通过事件处理程序实现某些效果。那么,究竟什么样的代码可以放在代码隐藏文件里?这些代码是否包含原本应该放在视图模型里的代码?这些效果是否还有其他途径可以实现?

视图模型从字眼上看应该是视图的抽象,这意味着每个视图都应该有一个对应的视图模型,这也是我们经常看到的做法。不过,有人对此表示反对,他们认为视图和视图模型不是一一对应的关系,整个应用程序应该有一个主要的视图模型,各个视图将会绑到这个主要的视图模型上,同时有一些次要的视图模型,用来表示诸如配置等辅助方面。那种做法才是正确的?视图模型里面又该包含什么样的代码?

最后是模型,大多数人对它的一个共识就是,它会包含具体的数据,这些数据最终会显示到用户界面上。问题是,它到底是简单的POCO还是业务逻辑的复杂类型?我们是否应该在这里放置验证逻辑?是否允许它和视图直接绑定,还是需要另外创建对应的包装类?如果使用LINQ to SQL存储数据的话,模型里的类是否就是LINQ to SQL的实体类?如果需要访问Web Service获取数据,模型里的类和添加Web Service时自动生成的类又是什么关系?

哇,问题还真不少啊!你是否曾经遇到这些问题?你对它们有什么想法?诚然,这些问题没有唯一的标准答案,它们都是开发者在具体实践中提炼和总结出来的智慧,但它们通常只针对于特定的应用场景,或者说,它们是为了满足某些需要而产生的。举个例子吧,有些人可能会觉得添加Web Service时自动生成的类和他们要创建的模型类基本上是一致的,为了避免重复劳动,他们选择直接使用那些自动生成的类,这种做法一般不会出现问题,直到由于需求的变更,模型不再和Web Service对应起来,但此时应用程序的其他部分已经通过这些自动生成的类和Web Service紧密耦合起来了,修改应用程序就可能变得非常困难。相反,如果应用程序的功能比较单一、专注,Web Service的接口也比较稳定,那么特意为那些自动生成的类创建一组一模一样的模型类显然增加劳动成本,埋下潜在的维护问题。

最简单的实现

假设我经常去图书馆借书,我需要一个应用查看所有图书的归还日期,如图2所示:

图 2

这是一个非常简单的应用,从MVVM模式的角度来看,图2所展示的用户界面就是视图了,而视图模型和模型也都非常简单,分别为图3的MainViewModel类和Book类:

图 3

页面的ListBox控件将会绑到MainViewModel的Books属性,书名将会绑到Book的Title属性,而归还日期则绑到Book的DueDate。

到目前为止,一切都非常自然顺畅,直到我对它提出两个新的需求:

  • 图书列表根据归还日期从小到大排序,即最先要还的书拍在最上面。
  • 今天和明天要还的书字体使用强调色。

这两个新的需求都非常合理。第一个需求属于页面的抽象逻辑,不与页面的任何控件挂钩,这种需求一般会在视图模型里面实现,具体地就是在MainViewModel的构造函数里初始化Books属性时进行升序排序。

至于第二个需求,它涉及到具体的TextBlock控件以及对Book类的DueDate属性的二次处理,原则上不应该在Book类里面实现,根据个人偏好,这个需求有两种不同的实现方式:

  • 创建一个ItemViewModel类,包装Book类并暴露相关属性,同时提供一个Foreground属性用于和TextBlock控件的对应属性绑定,Foreground属性可以在初始化ItemViewModel时根据Book的DueDate属性计算。
  • 通过转换器实现相同的效果。

有人说,使用MVVM模式可以消除转换器的需要,是的,任何时候当你需要一个转换器,你都可以通过创建包装类并提供额外的属性获得相同的效果,但我们不应该把这个问题绝对化,转换器的存在价值体现在可以在不同的绑定关系上重用相同的逻辑,而且更符合Expression Blend用户的使用习惯。

看到这里,有些同学可能会问,如果用户要求同时提供根据图书标题和归还日期两种排序方式呢?每当我们遇到一个新的需求时,请不要马上动手实现或者考虑如何实现,应该先想想用户为什么有这样的需求。根据归还日期进行排序这个需求对应着帮助用户避免逾期归还所受的惩罚,但根据图书标题排序呢?很多时候,我们会想当然地认为用户需要某些功能,而忽略用户真正的需求,这样不但会导致功能冗余,还会分散用户对于最重要功能的注意。事实上,根据图书标题排序这个需求很可能是想帮助用户了解某本书是否已经存在于列表中,或者某本书的具体信息,如还可以读多久,本质上,这个需求很可能是帮助用户从列表中快速查找某本书。如果是这样,为什么不考虑给出一个即时搜索的功能,比如说,当用户单击搜索按钮时,会显示一个搜索框,用户在里面输入关键字,图书列表马上显示包含该关键字的图书?

命令与操作

到目前为止,这个应用几乎可以说一无是处,因为它不支持添加、编辑和删除等操作,那么,实现这些操作又有哪些东西需要考虑呢?假设我们在用户界面上添加相应的按钮和菜单,如图4所示:

图 4

以往的做法是在代码隐藏文件里通过事件处理程序来实现,但在MVVM模式里,我们提倡通过命令对象来实现,问题是,这些命令对象在哪实现?添加操作是页面范围的,与之对应的命令对象可以在MainViewModel类里实现,但编辑和删除两个操作对应于Book类,那么,我们是否应该在Book类里添加相应的行为?

有一部分人对此的观点是,模型并非单纯的POCO,而是完整的领域模型,可以包含区别于页面逻辑的业务逻辑,并且不会和ORM的实体类等同起来,这样做的好处是我们有一个统一的地方来维护整个应用的状态,也和具体的数据层解耦,无论数据最终来自本地还是远程服务,都不会影响在此之上的东西,与此同时,我们也不必在为不同的视图模型之间如何传递数据感到烦恼。当然,这样做的坏处也是明显的,它引入了大量可能不必要的复杂性,对于小型项目具有不少杀伤力。

如果我们不在Book类里添加行为,又不想在代码隐藏文件里通过事件处理程序来实现这些操作,那么我们就需要考虑一下Expression Blend的行为(Behavior)了。具体的想法是这样的,假设用户单击编辑菜单项的时候将会打开EditItemPage.xaml页面,而这个页面需要知道用户选中哪本图书,那么整个操作就可以看作通过NavitagionService.Navigate方法打开“EditItemPage.xaml?title=XXX”这样的链接了。要实现这样的效果,你可以使用AppBarUtils for Windows Phone SDK 7.1的NavigateWithQueryStringAction,如代码1所示:

<AppBarUtils:NavigateWithQueryStringAction TargetPage="/EditItemPage.xaml"> 
<AppBarUtils:Parameter Field="title" Value="{Binding Title}"/> 
</AppBarUtils:NavigateWithQueryStringAction> 

代码 1

配合EventTrigger在MenuItem上使用就可以实现预期的效果了。

除此之外,你也可以考虑创建一个ItemViewModel类,然后在上面实现编辑操作的命令对象,然后和MenuItem的Command属性进行绑定。如果你选择这种做法,就会无可避免地遇到在视图模型里打开页面的问题。我们通常用来打开页面的NavitagionService.Navigate方法必须在页面的范围内才可访问,但视图模型对于视图一无所知,怎么调用这个方法?

常见的做法是封装PhoneApplicationFrame的Navigate方法。当你用Visual Studio创建一个Windows Phone项目时,App类里面会有一个RootFrame属性,你可以通过这个属性调用PhoneApplicationFrame的Navigate方法。事实上,PhoneApplicationFrame和页面是共用同一个NavitagionService对象的。

删除操作是一种很特别的操作,它同时涉及到集合以及里面的元素,但在XAML里,MenuItem只能从父元素继承对应的Book对象,却无从知晓包含该对象的集合,这为实现删除操作造成极大困扰。常见的解决办法是把MainViewModel作为一个静态属性放在App类里,这样你就可以轻易访问到包含Book对象的Books集合。从这个角度来看,如果我们一开始就把模型设计成领域模型,负责管理和维护领域对象的状态,那么现在就不必把某个视图模型硬塞到App类里了。

应用程序栏以及其他

在Windows Phone上使用MVVM模式必定会遇到的一个障碍就是应用程序栏,它的问题在于它不是Silverlight控件,而是系统组件,这意味着它无法像通常的Silverlight控件那样进行数据绑定。市面上有不少解决方案,其中之一就是前面提到的AppBarUtils for Windows Phone SDK 7.1,有兴趣的可以看看Allen Lee写的《AppBarUtils使用指南》

如果你把模型设计成领域模型,那么你一定要注意Windows Phone的“深度链接”(deep link),这种情况会在你使用Toast通知和次要磁贴(secondary tile),并在用户单击打开应用的某个页面时出现。由于用户仅对某个页面感兴趣,而且当用户按返回键时会直接退出应用而不是按照应用的常规逻辑返回上一页,因此构建整个领域模型会显得劳师动众、耗费资源。

有人认为,使用MVVM模式的一大好处是为Expression Blend用户带来便利,确实是这样,数据绑定和命令对象的应用使得Expression Blend用户更易通过可视化操作使用开发人员的后台代码。如果你的视图模型也会给Expression Blend用户使用,那么你必须考虑的一点就是在视图模型里提供设计时数据,尤其是你的逻辑包含访问本地数据库或者Web Service,因为在Expression Blend的设计器里无法执行这些代码。

最后不得不提的是,MVVM模式使得我们可以绕过用户界面对应用的功能进行测试,包括单元测试,如果你有兴趣,可以看看Chenkai的《Windows phone 应用开发[9]-单元测试》


感谢侯伯薇对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

MVVM的优势 by Li Ryan

请问作者,MVVM比起传统的开发真正优势在哪?代码量少?易于维护的代码?方便UI数据层的单元测试(UI的单元测试项做全,不好做,UI上的交互必定牵扯到控件,而非控件的交互,在传统的XAML开发中,我们又有多少代码在UI层是非控件的交互呢,10%?20%?30%?)?UI设计与UI业务逻辑分开(传统的开发业一样可以,事件挂接,DataContext数据binding)?还是其他什么的?如果没有真正对开发,或者整个团队没有真正实用价值的我们为什么要去学呢?反而增加了开发人员的学习成本,以及维护成本,而且silverlight中有少部分控件对MVVM的支持也不是很好,而且为了MVVM可能会去写一些而外的代码,这样岂不是为了模式而模式?

Re: MVVM的优势 by 张 鑫

ZK也是应用 MVVM 的一个例子: books.zkoss.org/wiki/Small_Talks/2011/October/H...

标题党而已 by Chan Jason

启示录这样的名字都敢用,infoq就这样的文章?

视图和视图模型不是一一对应的关系? by shi andy

视图和视图模型应该不是一一对应的关系,如果是一一对应,那不就是code-behind的了吗?分离应该是提高UI逻辑的可测试性,视图的可切换性。

Model应该是POCO! by shi andy

Model应该是简单的POCO,体现传递的数据,应该对前端屏蔽复杂的业务对象!!业务对象应该只给业务逻辑用!

绑定视图的应该是试图模型! by shi andy

绑定视图的应该是视图模型,也就是ViewModel,ViewModel中还包含前端的验证和前端的业务逻辑!

Re: 绑定视图的应该是试图模型! by shi andy

对Model数据的合并之类的

MVVM by 李 中华

简单业务逻辑,POCO确实方便,复杂业务逻辑,还是领域模型好,程序员能较好的管理逻辑代码.
使用Web Service的DTO来当成视图绑定的模型,这对于快速开发很有帮助.但一般限制与简单需求.
另外,这个的使用,与WebService是数据型还是业务性也有关系,如果WebService是粗粒度的数据服务,客户端就有可能会获取很多不需要的数据.对于大量数据的网络传输,这是要命的.
视图模型,我尝试过一个模型对应多个视图,这样有好处,比如订单,订单明细,订单历史这三个视图属于一个视图模型,有些功能实现的非常容易(比如在订单明细中添加了一条明细后,订单页能立刻同步UI上的显示). 但也有不好的地方,就是视图模型类变的很大.当然也可以通过另外一个控制类来解决这个庞大类的问题.

此时我想起一句话,当我们引入一种方法解决一个事情时,同时有带来了另外一个问题.

该怎么选择,这个要看项目的架构决策人去具体问题具体分析了.

Re: MVVM的优势 by 王 迅

国外搞SL和WPF的都流行三年MVVM了,居然还有人问出这种问题

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

9 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT