WPF中MVVM模式原理分析与实践

WPF中MVVM模式原理分析与实践2011-03-31周银辉1, 前提

可以说MVVM是专为WPF打造的模式, 也可以说MVVM仅仅是MVC的一个变种, 但无论如何, 就实践而言, 如果你或你的团队没有使用"Binding"的习惯, 那么研究MVVM就没有多大意义.

另外,个人觉得, 使用Command以及打造一种合理的简化的方式去使用Command也与使用 Binding一样重要.

2, 诞生

为了解决现实世界中的问题,我们需要将现实世界中的事物加以抽象, 然后得到了 Domain Object, 无论贫血的还是富血的, 我们都可以简单地把他们归结为"由现实世界抽象出来的模型", 也就是我们的model, 也就M-V-VM中的"M"。

但其无法与我们的用户进行交互, 所以, 我们需要为其创建一个界面（视图, View）, 该视图可以与用户输入设备进行交互, 这很棒, 但问题是如何将View与我们的model关联起来？ Binding便可以发挥作用了, 比如视图上的某一个文本框中的文本和Model中的"用户名"关联起来, 用户便可以通过操作该文本框来访问和修改Model的"用户名"了。

这是极其简单的情况, 但实际编程时我们发现, Model中的属性（与方法）往往不那么容易与View中的界面控件关联起来, 比如, "类型不匹配": 界面控件所需要的类型与模型中属性提高的类型不匹配. "需要额外操作": 模型中的数据需要经过一些额外的处理才能传给视图,反之亦然. 此时, 我们意识到View似乎需要一个"Helper"类来处理一些额外工作.

这个helper所包含的代码可以放在除了Model外的很多地方（我们现在不考虑贫血富血之类的争论）, 比如View中, 记得自己刚学习窗体程序开发时就是这么干的, 将绝大多数处理逻辑放在那个所谓的CodeBehind中. 后来,正如大家在各种设计模式书籍中所看到的一样,为了将View和Model剥离开来,实现view可替换（比如你可以讲自己精心设计的软件同时运行于窗体程序,Web甚至Mobile上）, 便有了MVC. 有了MVC以后似乎就开始滋生M-V-XXX 之类的争论与变种模型, 比如MVP以及这里的MVVM,甚至MVP也有着Supervising Controller与Presentation Model两种方式. 但主要围绕两个问题,一是model与view之间的关系, 完全隔离的？单向的还是双向的？二是这个"XXX"需要完成哪些功能,简单流程调度？复杂规则处理？ OK,这些争论都没有关系, 是否采用某种模式取决于你的开发所处的环境（比如语言特性,框架特性）以及你的业务特性以及所面临的主要变化点等等。

但与MVC,MVP所不同的是,MVVM的引入不仅仅是技术上的原因（解除耦合应对变化等老生常谈）,另外一个很大原因是:软件团队开发方式的改变.如果你做过一段时间的WPF项目开发的话,你可能会有比较明显的感觉:在View层打造上,如何分配程序员和美工的工作.在继续阅读之前,大家可以看看我以前的一篇文章"在UI Designer与Developer之间". 以前我们团队采用的便是"集成模式", 我便兼职了其中的"Integrator"角色.这还不错.但说实在的,这仅仅是一个在特殊情况下不得已而为之的暂时方案,所以我们付出了很大的努力开始转向"收割模式"了,要转向这个模式,至少需要两个基本条件:

（1）你拥有能够熟练运用Blend等工具能为程序员输出XAML的美工, 他专注于纯粹的 UI/UE, 另外他还必须具有一定的"程序员"思维.以便输出的东西能很好地作为程序的一部分而运转起来,而不是仅仅"看上去"是那样的。