【转】MVP和MVC的区别

转自：http://www.cnblogs.com/end/archive/2011/06/02/2068512.html

MVC和MVP到底有什么区别呢？ 

从这幅图能够看到，咱们能够看到在MVC里，View是能够直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。

在MVC模型里，更关注的Model的不变，而同时有多个对Model的不一样显示，及View。 

因此，在MVC模型里，Model不依赖于View，可是View是依赖于Model的。不只如此，由于有一些业务逻辑在View里实现了，致使要更改View也是比较困难的，至少那些业务逻辑是没法重用的。

Visual Studio等快速开发工具，让咱们很难把View和Controller分开，咱们老是直接在View的事件响应函数里完成了Controller的代码。而在ASP.NET和XAML里，使用了一种叫作Code-Behind的技术，能够把View和Controller进行分离。这样，View就能够彻底由UI设计工程师来完成，而Controller由程序员来完成，二者能够直接合成不须要像如今同样再由程序员作不少的工做。 

把Controller和View混在一块儿，有什么问题？

１.难以测试。

　　必须手动点击，使用各类自动化的测试工具。

２.代码难以重用。

　　UI是很难重用，由于要求老是不一样。因此，致使重复的代码四处都是，维护麻烦。

MVP是如何解决MVC的问题的？

在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很大的不一样之处。

参考：

MSDN的MVP介绍 
一个不错的视频演示 
Presenter First 
The Humble Dialog 
-----------------------------------------------

Alex在他的blog中对于mvc 与mvp 之间的比较：

【译文】：

Model View Presenter vs Model View Controller
简介

在我工做中常常须要处理一些因为开发人员没能很清楚地理解MVC和MVP模式的区别的状况下使用它们而产生的问题。在这篇文章中我将会阐述一下我对二者之间区别的一些理解。
在N层体系结构中MVC/P 模式仅仅只是用于表示层(presentation layer)，理解这一点很重要。这两个模式并非关于怎么构建数据层(data layer)和服务层(service layer)的，而是关于怎么将数据(data)从用户接口(view)中分离出来，以及用户接口如何与数据进行交互的。这些模式的使用让解除你的程序中表示层对对数据和控制逻辑的依赖，从而能够自由的变动表示层。

这两种模式中三个部分的通常理解

一、模型(Model)表示数据模型和业务逻辑(business logic)。模型并不老是DataSet，DataTable之类的东西，它表明着一类组件(components)或类(class)，这些组件或类 能够向外部提供数据，同时也能从外部获取数据并将这些数据存储在某个地方。简单的理解，能够把模型想象成“外观类(facade class)”。【译注：这里的外观是指“外观模式”中所说的外观。外观的通常做用是为一个复杂的子系统提供高层次的简单易用的访问接口，能够参看下面的图来理解它的原理：

】
二、视图(View)将数据层现给用户。通常的视图都只是包含用户界面(UI)，而不包含界面逻辑。好比，Asp.net中包含控件的页面(page)就是一个视图。视图能够从模型中读取数据，可是不能修改或更新模型。
三、层现器(Presenter)/控制器(Controller)包含了根据用户在视图中的行为去更新模型的逻辑。视图仅仅只是将用户的行为告知控制器，而控制器负责从视图中取得数据而后发送给模型。

MVC/P模式的核心是为了将模型从视图/控制器中分离出来，从而使得模型独立于它们，所以模型不包含对视图和控制的引用。

什么是MVC(Model View Presenter)模式?

一、为了使得视图接口能够与模型和控制器进行交互，控制器执行一些初始化事件
二、用户经过视图（用户接口）执行一些操做
三、控制器处理用户行为(能够用观察着模式实现)并通知模型进行更新
四、模型引起一些事件，以便将改变发告知视图
五、视图处理模型变动的事件，而后显示新的模型数据
六、用户接口等待用户的进一步操做

这一模式的有一下几个要点：
一、视图并不使用控制器去更新模型。控制器负责处理从视图发送过来的用户操做并经过与模型的交互进行数据的更新
二、 控制器能够和视图融合在一块。Visual Studion中对Windows Forms的默认处理方式就是这样的。【译注：好比咱们双击一个Button，而后在它的事件里写处理逻辑，而后将处理的数据写回模型中。这里处理逻辑时 间应该是控制器的功能，可是咱们并无专门写一个控制器来作这件事情而是接受了VS的默认处理方式，将它写在Form的代码中，而这里的Form在MVC 中它就是一个View。因此这说vs默认的处理方式是将把控制器和视图融合在一块儿的。】
三、控制器不包含对视图的渲染逻辑(rendering logic)

“主动—MVC”模式，也是一般意义下的MVC模式

【译 注：为何说是主动的？View不是等Controller通知它Model更新了而后才从Model取数据并更新显示，而是本身监视Model的更新 (若是用观察者模式)或主动询问Model是否更新。前面那种等待Controller通知的方式是下面所介绍的“被动—MVC”的实现方式。】

“被动—MVC”模式
与主动MVC的区别在于：
一、模型对视图和控制器一无所知，它仅仅是被它们使用
二、控制器使用视图，并通知它更新数据显示
三、视图仅仅是在控制器通知它去模型取数据的时候它才这么作(视图并不会订阅或监视模型的更新)
四、控制器负责处理模型数据的变化
五、控制器能够包含对视图的渲染逻辑

MVP模式

与“被动—MVC模式”很接近，区别在于“视图并不使用模型”。在MVP模式中视图和模型是彻底分离的，他们经过Presenter进行交互。
Presenter与控制器很是类似，可是它们也有一些的区别：
一、Presenter处理视图发送过来的用户操做（在MVC中视图本身处理了这些操做）
二、它用更新过的数据去更新模型（在被动MVC中控制器只是通知视图去更新过的模型中去取新的数据，而主动MVC中模型通知视图去更新显示，控制器不须要作工做）
三、检查模型的更新（与被动MVC同样）
四、（与MVC的主要区别）从模型中取数据而后将它们发送到视图中
五、（与MVC的主要区别）将所作的更新告知视图
六、（与MVC的区别）用Presenter渲染视图

MVP的优点

一、模型与视图彻底分离，咱们能够修改视图而不影响模型
二、能够更高效地使用模型，由于因此的交互都发生在一个地方——Presenter内部
三、咱们能够将一个Presener用于多个视图，而不须要改变Presenter的逻辑。这个特性很是的有用，由于视图的变化老是比模型的变化频繁。
四、若是咱们把逻辑放在Presenter中，那么咱们就能够脱离用户接口来测试这些逻辑（单元测试）

MVP的问题

因为对视图的渲染放在了Presenter中，因此视图和Persenter的交互会过于频繁。

还有一点你须要明白，若是Presenter过多地渲染了视图，每每会使得它与特定的视图的 联系过于紧密。一旦视图须要变动，那么 Presenter也须要变动了。好比说，本来用来呈现Html的Presenter如今也须要用于呈现Pdf了，那么视图颇有可能也须要变动。

MVP模式根据 Module，View，Presenter之间的交互，能够分为Passive View(常规MVP)和Supervising Controller 2种。

Passive View模式：

大 家会发现MVP与MVC最大的一个区别就是“Model与View层之间倒底该不应通讯（甚至双向通讯）。我想这也是目前作这两方面研究的专家所互相争论 的战场。一定各有各的好处和因好处要付出的代价。起码在MVP模式下的Presenter要拥有“绝对权力”。若是没有它，MODEL与View就是两个 孤岛，尽管各有各的地盘（彻底解耦），但不会给企业带来什么有用的价值。

因此我这里有一个比喻来形容MVP中的：
Presenter ----就是一个控制欲极强的女人，甚至就连“用什么姿式”，它都要管一管。
当 然日里万机操心多了就会让本身要作的事愈来愈多，最终它面临的就是该层代码日益庞杂，且书写起来不太方便，一定就连事件绑定这类鸡毛算皮的事都要归它管， 累不累呀。最终咱们看到MVP中的View就真的代码轻闲了很多（国企职工嘛），难怪说View只要从相应的[IVIEW]接口下实现相应的属性和一些简 单方法就完事了，而最终调用[IVIEW]接口下的那个视图实例则彻底交给了Presenter，这让我想到了MVC中能够支持“自定义模版引擎（最终由 MVC框架来控制使用系统仍是自定义的模版引擎）”以及平时你们常挂在嘴边的换肤功能，想到这里多少还真有那么点意思了（精神层面上）。

固然在微软内部对MVP的理解也有所不一样，以下面中所说的 Supervising Controller模式和以前你们看到的PassiveView. Supervising Controller模式其实很接近于MVC的那张图了，只是又提供了Presenter与View之间的“双向通讯”。这种作法也是有不少不一样意见的，起码对那些支持“单向依赖”的开发者而言是“嗤之以鼻”的。 说到这里，虽然PassiveView模式有些霸道，但一定是让Model和View之间真正解耦，为开发者提供了最大的“控制成就感”，能够说想怎么控制视图就怎么控制，但所以所形成的问题就是代码书写量和实现复杂性等问题了。