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

核心提示：1, 前提可以说MVVM是专为WPF打造的模式, 也可以说MVVM仅仅是MVC的一个变种, 但无论如何, 就实践而言, 如果你或你的团队没有使用"Binding"的习惯, 那么研究MVVM就没有多大意义.另外,个人觉得, 使用Command以及打造一种合理的简化的方式去使用Command也与使用Bi

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,这些争论都没有关系, 是否采用某种模式取决于你的开发所处的环境(比如语言特性,框架特性)以及你的业务特性以及所面临的主要变化点等等。