说不尽的MVVM(1) – Why MVVM

最近学的一篇课文《说不尽的狗》竟让我有了写《说不尽的MVVM》这一想法，事非亵渎,实出无奈。我在刚学WPF不久时听说有MVVM这种东西，做了下尝试，发现他能给程序的设计带来很大的好处。好东西当然要分享给大家，下面，我们就来认识下MVVM。

预备知识

阅读本文，我假定你具备以下知识：

• C# 基础知识
• XAML基础知识
• 对事件驱动模型的了解
• 听说过MVC、MVP、单元测试

MVVM是什么，好吃吗？

MVVM全称为Model-View- View Model，是软件工程中的一种软件设计模式，相信很多朋友都知道 MVC (Model-View-Controller) 和 MVP (Model-View-Presenter) 。为了使软件在健壮性、代码重用和结构方面更上一个层次，人们相继提出了MVC和MVP，MVP主要用在WinForm和WebForm里面，实现UI、数据和业务业务逻辑的分离。MVVM的目标和思想MVP类似，但MVVM建立在WPF、Windows Phone、WinRT等基于XAML的表现层技术之上，利用数据绑定(Data Binding)、依赖属性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性，打造了一个更加灵活高效的架构。

至于好不好吃，试过才知道:D

给我一个用MVVM的理由

传统的事件驱动模型（前）和MVVM模式（后）

这两张图是传统开发模式和MVVM模式的逻辑处理简化图，上面说到MVVM灵活和高效，主要体现在以下几方面

数据驱动UI

事件驱动的程序设计模型在传统的WinForm开发模式中最常见不过了，包括WPF也支持这种模式。在这种模式中，程序的主角是UI，通过UI控件事件的触发对数据进行处理，然后更新UI。整个过程中，UI处于主导地位，数据处于被动状态，在事件处理代码执行完成后，数据被转化成了UI控件的状态。

在MVVM中，数据和逻辑处于一个独立的View Model中，由View Model中的逻辑对数据进行处理，数据处于主动地位， UI的任务是关注数据的更改并将它显示出来，数据不再属于UI，真正成为程序的主角。

更低的耦合度

从上面两张图可以看到，在传统的事件驱动模式中，更新UI时不可避免的要引用UI上的对象，如果要从UI上获取输入，还需要访问UI对象的属性，这样的逻辑是离不开UI的，一旦UI发生改变，即使后台逻辑不变（比如将输入用的TextBox换成Slider），后台代码就要变，痛苦可想而知。

MVVM模式中，数据是独立于UI的，数据与UI的耦合是松散的，View Model把数据以属性的形式暴露出来。UI要做的事情，就是把数据"送过来"，把数据"拿回去"。

更新UI不抓狂

在传统的开发模式中，在工作线程中更新UI是一件非常麻烦的事情，这也是UI驱动数据带来的负面影响之一，在MVVM中，我们可以在工作线程中直接修改View Model的数据（只要数据是线程安全的），剩下的数据绑定帮你搞定。

更高效的团队协作

MVVM的分工是非常明显的，View Model 负责提供数据，View负责展现数据，由于View和View Model之间是松散耦合的，完全可以让程序员一边写View Model，设计师一边用Blend设计View，同时工作，效率更高。

更好的复用性

上面说到View Model独立于UI，不妨把UI理解成数据的衣服，衣服可以换，UI当然可以换，我们可以把同一个View Model用到多个View中，比如桌面版的程序和Win8 App甚至是 Windows Phone共用一个View Model。

更好的可测试性

既然View Model里面是数据和业务逻辑，因此，不用等到UI写好，我们已经可以用单元测试去检测业务逻辑的正确性了。

需要准备什么

.NET Framework 4.5

Visual Studio

MVVM light toolkit

Windows 8 / Silverlight / Windows Phone 的SDK任选一个