MVVM模式应用 之介绍

M-V-VM

（1）M:即Model,由现实世界抽象出来的模型；

V:即View,视图，界面，该界面与用户输入设备进行交互；

但是View与Model如何进行交互呢?

Binding便可以发挥作用了, 比如视图上的某一个文本框中的文本和Model中的"用户名"关联起来, 用户便可以通过操作该文本框来访问和修改Model的"用户名"了。

（2）但实际编程时我们发现, Model中的属性(与方法)往往不那么容易与View中的界面控件关联起来。

往往"需要额外操作": 模型中的数据需要经过一些额外的处理才能传给视图,反之亦然。 此时, 我们意识到View似乎需要一个"Helper"类来处理一些额外工作.

这个helper所包含的代码可以放在除了Model外的很多地方(我们现在不考虑贫血富血之类的争论), 比如View中。

而且我们都是这么做的，将绝大多数处理逻辑放在那个所谓的CodeBehind中。

（3）后来，在各种设计模式书籍中所看到的一样,为了将View和Model剥离开来,实现view可替换，便有了MVC。

有了MVC以后就开始有了MVP 、MVVM等等M-V-XX。

但主要围绕两个问题,

一是model与view之间的关系, 完全隔离的?单向的还是双向的?

二是这个"XX"需要完成哪些功能,简单流程调度?复杂规则处理?

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

（3）但与MVC,MVP所不同的是,MVVM的引入不仅仅是技术上的原因(解除耦合应对变化等老生常谈)，另外一个很大原因是:软件团队开发方式的改变。

我们需要一种方式将View层的代码逻辑抽取出来,并View层很纯粹以便完全让美工去打造它.相应地, 需要将View层的相应逻辑抽取到一个代码层上,以便让程序员专注在这里。

这就需要：

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

　　《2》你需要能够脱离View层但仍能编写出高质量代码的程序员。

（4）回想一下, 我们之所以要在View(Xaml)背后写一些代码(C#), 无非是想传递一些数据以及传递数据时的数据的处理或在用户与界面控件进行交互时执行一些操作。

最简单的例子是在MVC中当界面发生交互时View去调用Controler中的某个方法, 以便将该操作的相应"指示"传递到"后台"去.

在以前的技术中, 这样的"衔接性"的代码是必须的.

而在WPF中, 则可以通过另外的技术来进行层与层之间的"衔接", 这就是"Binding" 和"Command", 以及"AttachBehavior"。

（5）通过Binding, 我们可以实现数据的传递;

　　  通过Command, 我们可以实现操作的调用

Binding和Command是可以写在XAML中的, 这样看来XAML后面对于的CS文件可以被完全抛弃或不予理会了. 这样的XAML文件正是美工所需要的.

而这些对于Binding以及Command的定义描述以及其他相关信息的代码应该放在那里呢, 当然不是View, 更不是Model, 是"ViewModel".

ViewModel是为这个View所量身定制的, 它包含了Binding所需的相关信息,比如Converter以及为View的Binding提供DataContext, 它包含了Command的定义以便View层可以直接使用, 另外,它还是一个变种的Controler, 它得负责业务流程的调度。

这个图应该能看懂了吧？

（6）AttachBehavior

一般情况下利用Command, Binding, AttachProperty等WPF特性, View和ViewModel之间能配合工作得很好. 假设我们有一个Button, 当该Button被点击的时候我们要完成一些操作, 很简单, 将该操作封装成一个Command并绑定到该Button上就可以了, 但如果我们要在Button被Load的时候执行另外一些操作呢? 由于Button没有直接被Load事件所触发的Command, 所以不能使用Command了. 不能直接将Load事件处理器写在Button所在的Xaml所对应的CS文件里, 这和我们刚才对MVVM的设计是相矛盾的. 一个不太好的方案是继承一下Button, 并撰写一个由Load所触发的Command, 这可行, 但明显不好. 正如一个控件没有某个属性并且在不继承的情况下而采用AttachProperty一样, 我们可以采用AttachBehavior.