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

核心提示： 回想一下, 我们只所以要在View(Xaml)背后写一些代码(C#), 无非是想传递一些数据以及传递数据时的数据的处理或在用户与界面控件进行交互时执行一些操作, 最简单的例子是在MVC中当界面发生交互时View去调用Controler中的某个方法, 以便将该操作的相应"指示&qu

回想一下, 我们只所以要在View(Xaml)背后写一些代码(C#), 无非是想传递一些数据以及传递数据时的数据的处理或在用户与界面控件进行交互时执行一些操作, 最简单的例子是在MVC中当界面发生交互时View去调用Controler中的某个方法, 以便将该操作的相应"指示"传递到"后台"去. 在以前的技术中, 这样的"衔接性"的代码是必须的. 而在WPF中, 则可以通过另外的技术来进行层与层之间的"衔接", 这就是"Binding" 和"Command", 以及稍后我们会提到的"AttachBehavior". 通过Binding, 我们可以实现数据的传递; 通过Command, 我们可以实现操作的调用.(AttachBehavior的作用稍后再谈). Binding和Command是可以写在XAML中的, 这样看来XAML后面对于的CS文件可以被完全抛弃或不予理会了. 这样的XAML文件正是美工所需要的. 而这些对于Binding以及Command的定义描述以及其他相关信息的代码应该放在那里呢, 当然不是View, 更不是Model, 是"ViewModel". ViewModel是为这个View所量身定制的, 它包含了Binding是所需的相关信息,比如Converter以及为View的Binding提供DataContext, 它包含了Command的定义以便View层可以直接使用, 另外,它还是一个变种的Controler, 它得负责业务流程的调度。

于是, 便有了这副图, 然后, 正如"时势造英雄"所言, MVVM就诞生了.

3, ViewModel 与单元测试

如果你是一名正在使用MVVM模式打造软件的程序员, 那么我劝你尽快忘掉View. 你所面对的是这样一个模式"UnitTest-ViewModel-Model"(这并非一个模式, 仅仅是我为阐述观点而暂时如此表述的)。

记得曾经有一个Model-View-AbstractView模式, 而MVVM中的VM实际也是一个AbstractView: the abstraction of view. 它是一个抽象的View, 具有一个View的灵魂,而不具备相应的可视化控件而已. 所以对于程序员而已, 打造这样一个抽象的VM就可以认为是完成View层的打造了.而当美工完成无数控件组成的实际的View后, 我们就可以用Binding和Command这样的黏合剂将这个抽象的View和实际的View黏合在一起了。