在我们深入理解这两者差异前让我们研究设计模式如何工作和更好使用两种（ MVC设计与MVP ）之一。 （ MVC设计与MVP ）模式已使用了好几年，解决的一个关键问题即面向对象主要关注点，分离的用户界面和业务层。

还有一些框架，是目前使用的是基于这些模式包括： JAVA Struts, ROR, Microsoft Smart Client Software Factory (CAB), Microsoft Web Client Software Factory，

以及最近宣布ASP.Net MVC framework. 框架。

模型视图控制器（ MVC设计）模式

在MVC模式是一个用户界面演示模式，重点是从业务层（Model）分离的用户界面（View） 。该模式在职责分开三部分组成：view 负责渲染UI元素  ， 控制器controller 负责响应用户界面的行动，

该模型（Model）是负责业务的行为和状态管理。在大多数执行所有三个组成部分可以直接相互交流，在一些实施的控制器负责确定其中view显示（Front Controller Pattern） ，

模型认为主持人（ MVP ）模式

（ MVP ）模式 是一个在MVC模式基础上的概念MVC模式。模式职责分开四个部分组成：view 负责渲染UI元素，界面接口被用于解牛控制它的 (presenter)主持人， presenter 主

界面接口和服务层通常用来简化presenter和model模式的单元测试。

主要优点

在使用任何模式一开发商需要考虑的优点和缺点的后再使用它。有一些关键的优点 可决定使用MVP或MVC模式（见下面的列表） 。

但是，也有少数人提请审议支持。最大的缺点是额外的复杂性和学习曲线。虽然模式可能并不适合简单的解决方案;不过解决方案可以极大地受益于使用模式。

我体验是我用到了几个模式解决方案，模式消除了大量的复杂，但我正在重新考虑更好的使用模式。

松散耦合- presenter/controller在用户界面代码和模型 之间的扮演了中间人角色。这使得界面和模型 ，形成各自独立。

明确分开的问题/责任

1,view用户界面（表单或页面） -负责渲染U I元素

2,Presenter/controller主持人 -负责处理U I元素 事件和用户界面与模型 交互

3,model模型-负责业务行为和状态管理

测试驱动-通过孤立每一个主要component （用户界面，演示/控制器和模型）是比较容易写单元测试。尤其是当使用了MVP模式，这是为什么,Presenter只通过接口与view界面互交.

concerns/responsible

代码重用-通过使用关心或负责任的设计方法会增加代码的重用。尤其是当使用一个域模型和维持所有商业/状态管理逻辑在其混在一起时。

隐藏数据存取-使用这些模式逼着你把数据访问代码封装在一个数据访问层。还有其他一些典型的模式，与MVP/ MVC模式的数据存取。Two of the most common ones are repository and unit of work. (See Martin Fowler – Patterns of Enterprise Application Architecture for more details)

灵活性/适应性-通过隔震大部分的代码到主持人/控制器和模型组成的代码基础上更加适应变化。例如考虑多少UI和数据存取技术多年来改变了和有我们今天有可利用选择的数量。 一个适当的设计解决方案或使用的MVC MVP能够支持多个用户界面和一个数据同步。

主要区别

那么，真正的分歧MVP和MVC模式。其实不是很多的分歧。这两种模式的重点放在分离的责任跨越多组件和促进松散的耦合的用户界面（视图）从业务层（模型） 。主要分歧是如何实施的模式和一些先进的情景你既需要主持人和控制器。

这里是关键的分歧模式：

1 View 与model 更松散耦合的模式。主讲人是负责binding该model模型与view的。

The presenter is responsible for binding the model to the view.

2 容易单元测试，因为与view相互作用的是通过一个接口

3 通常presenters与view 一一对应。复杂的view可能会多presenters。

MVC模式

1 Controller 是基于行为的，可共享的 views

2  Can be responsible for determining which view to display (Front Controller Pattern)

希望你对这个文章感兴趣，它有助于澄清之间的分歧和MVP的MVC模式。如果不是这样，就算的模式是功能强大的工具，可很难使用有时。

有一件事需要记住的是，一种模式是一个蓝本，而不是一个彻头彻尾的方块的解决办法。开发人员应该根据自己的问题域使用它们作为指导和修改执行。