MVC、MVP、MVVM

1 简介

　　演变：MVC ——> MVP ——> MVVM

　　英文原文：MVC vs. MVP vs. MVVM

　　三者的目的都是分离关注，使得UI更容易变换（从Winform变为Webform），使得UI更容易进行单元测试。

　　MVC模式（Model-View-Controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

　　MVC模式的目的是实现一种动态的程式设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式通过对复杂度的简化，使程序结构更加直观。软件系统通过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：

• （控制器 Controller）- 负责转发请求，对请求进行处理。
• （视图 View） - 界面设计人员进行图形界面设计。
• （模型 Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

2 MVC/MVP

　　2.1 MVC

　　1、View接受用户的交互请求

　　2、View将请求转交给Controller

　　3、Controller操作Model进行数据更新

　　4、数据更新之后，Model通知View数据变化

　　5、View显示更新之后的数据

　　View和Controller使用Strategy模式实现，View使用Composite模式，View和Model通过Observer模式同步信息。Controller不知道任何View的细节，一个Controller能被多个View使用。MVC的一个缺点是很难对Controller进行单元测试，Controller操作数据，但是如何从View上断言这些数据的变化呢？例如，点击一个View的按钮，提交一个事件给Controller，Controller修改Model的值。这个值反映到View上是字体和颜色的变化。测试这个Case还是有点困难的。

　　2.2 MVP

　　1、View接受用户的交互请求

　　2、View将请求转交给Presenter

　　3、Presenter操作Model进行数据库更新

　　4、数据更新之后，Model通知Presenter数据发生变化

　　5、Presenter更新View的数据

　　Presenter将Model的变化返回给View。和MVC不同的是，Presenter会反作用于View，不像Controller只会被动的接受View的指挥。正常情况下，发现可以抽象View，暴露属性和事件，然后Presenter引用View的抽象。这样可以很容易的构造View的Mock对象，提高可单元测试性。在这里，Presenter的责任变大了，不仅要操作数据，而且要更新View。

　　在现实中，MVP的实现会根据View的充、贫血而有一些不同，一部分倾向于在View中放置简单的逻辑，在Presenter放置复杂的逻辑；另一部分倾向于在presenter中放置全部的逻辑。这两种分别被称为：Passive View和Superivising Controller。

　　在Passive View中，为了减少UI组件的行为，使用Controller不仅控制用户事件的响应，而且将结果更新到View上。可以集中测试Controller，减小View出问题的风险。

　　在Superivising Controller中的Controller既处理用户输入的响应，又操作View处理View的复杂逻辑。

---

附注：

　　MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。

MVC存在的问题：

　　在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。

MVP的解决方式：

　　在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。

　　而且，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！

　　不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试--而不需要使用自动化的测试工具。

　　 我们甚至可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。

　　在MVP里，应用程序的逻辑主要在Presenter来实现，其中的View是很薄的一层。因此就有人提出了Presenter First的设计模式，就是根据User Story来首先设计和开发Presenter。在这个过程中，View是很简单的，能够把信息显示清楚就可以了。在后面，根据需要再随便更改View，而对Presenter没有任何的影响了。 如果要实现的UI比较复杂，而且相关的显示逻辑还跟Model有关系，就可以在View和Presenter之间放置一个Adapter。由这个 Adapter来访问Model和View，避免两者之间的关联。而同时，因为Adapter实现了View的接口，从而可以保证与Presenter之间接口的不变。这样就可以保证View和Presenter之间接口的简洁，又不失去UI的灵活性。 在MVP模式里，View只应该有简单的Set/Get的方法，用户输入和设置界面显示的内容，除此就不应该有更多的内容，绝不容许直接访问Model--这就是与MVC很大的不同之处。

MVP的优点：

• 模型与视图完全分离，我们可以修改视图而不影响模型
• 可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
• 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
• 如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

MVP的缺点：

　　由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。

---

3 M-V-VM

　　因为WPF技术出现，从而使MVP设计模式有所改进，MVVM 模式便是使用的是数据绑定基础架构。它们可以轻松构建UI的必要元素。

　　MVVM是在原有领域Model的基础上添加一个ViewModel，这个ViewModel除了正常的属性意外，还包括一些供View显示用的属性。例如在经典的MVP中，View有一个属性IsCheck，需要在Presenter中设置View的IsCheck值。但是在MVVM中的Presenter也会有一个IsCheck属性来同步View的IsCheck属性，可能会用到Observer模式同步IsCheck的值。在MVVM中，Presenter被改名为ViewModel，就演变成了你看到的MVVM。在支持双向绑定的平台，MVVM更受欢迎。例如：微软的WPF和Silverlight。

MVVM的优点：

• 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
• 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
• 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。
• 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。

---

参考链接：

MVC wiki：http://zh.wikipedia.org/zh/MVC

http://blog.nodejitsu.com/scaling-isomorphic-javascript-code/#mvc

MVC，MVP 和 MVVM 的图示之简单展示

MVC vs. MVP vs. MVVM

从Script到Code Blocks、Code Behind到MVC、MVP、MVVM

MVVM模式原理分析及实践