MVC、MVP、MVVM

1 简介

  演变:MVC ——> MVP ——> MVVM
  英文原文:MVC vs. MVP vs. MVVM 

  三者的目的都是分离关注,使得UI更容易变换(从Winform变为Webform),使得UI更容易进行单元测试javascript

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

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

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

2 MVC/MVP

  2.1 MVCnode

  一、View接受用户的交互请求程序员

  二、View将请求转交给Controllerweb

  三、Controller操做Model进行数据更新算法

  四、数据更新以后,Model通知View数据变化数据库

  五、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

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

  二、View将请求转交给Presenter

  三、Presenter操做Model进行数据库更新

  四、数据更新以后,Model通知Presenter数据发生变化

  五、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模式原理分析及实践