以下是表示通信流程的图示

MVP

MVP代表模型-视图-演示者。2007年初，微软推出了Smart Client windows应用程序。

演示者在MVP中充当监督角色，MVP绑定模型中的视图事件和业务逻辑。

视图事件绑定将从视图界面在Presenter中实现。

视图是用户输入的发起者，然后将事件委派给演示者，演示者处理事件绑定并从模型中获取数据。

赞成的意见：视图只有UI，没有任何逻辑高水平的可测试性

欺骗：实现事件绑定时有点复杂，工作量更大

MVC

MVC代表模型视图控制器。控制器负责创建模型并使用绑定模型渲染视图。

控制器是启动器，它决定渲染哪个视图。

赞成的意见：强调单一责任原则高水平的可测试性

欺骗：如果试图在同一控制器中渲染多个视图，有时控制器的工作量太大。

我简短的观点是：MVP适用于大范围，MVC适用于小范围。有了MVC，我有时会觉得V和C可能被看作是一个不可分割的组件的两面，而不是直接绑定到M，当向下扩展到较短的规模时，如UI控件和基本控件时，必然会出现这种情况。在这种粒度级别上，MVP意义不大。相反，当一个人走向更大的规模时，适当的界面变得更重要，同样，明确的职责分配也同样重要，MVP就来了。

另一方面，当平台特性有助于组件之间的某种关系时，例如在web上，MVC的实现似乎比MVP更容易。

MVC（模型视图控制器）

在MVC中，控制器是负责人！控制器根据一些事件/请求触发或访问，然后管理视图。

MVC中的视图实际上是无状态的，控制器负责选择要显示的视图。

例如：当用户单击“Show MyProfile”（显示我的配置文件）按钮时，将触发控制器。它与模型通信以获得适当的数据。然后，它会显示一个类似于配置文件页面的新视图。控制器可以从模型中获取数据并将其直接馈送到视图（如上图所示），或者让视图从模型本身获取数据。

MVP（模型视图演示者）

在MVP中，视图是负责人！每个视图都会调用其演示者或演示者收听的某些事件。

MVP中的视图不实现任何逻辑，演示者负责实现所有逻辑，并使用某种接口与视图进行通信。

例如：当用户单击“保存”按钮时，视图中的事件处理程序将委派给演示者的“OnSave”方法。演示者将执行所需的逻辑，并与模型进行任何所需的通信，然后通过其界面调用视图，以便视图显示保存已完成。

MVC与MVP

MVC并没有让视图负责，视图充当控制器可以管理和指导的从属对象。在MVC中，视图是无状态的，而MVP中的视图是有状态的，可以随时间变化。在MVP中，视图没有逻辑，我们应该尽可能让它们保持沉默。另一方面，MVC中的视图可能有某种逻辑。在MVP中，演示者与视图分离，并通过接口与视图对话。这允许在单元测试中模拟视图。在MVP中，视图与模型完全隔离。然而，在MVC中，视图可以与模型通信，以使其与最新的最新数据。

我已经使用了MVP和MVC，尽管我们作为开发人员倾向于关注这两种模式的技术差异，但IMHO中MVP的要点与易于采用性比其他任何东西都更相关。

如果我所在的团队已经具备良好的web表单开发风格背景，那么引入MVP比引入MVC要容易得多。我认为MVP在这种情况下是一场快速的胜利。

我的经验告诉我，将团队从web表单转移到MVP，然后从MVP转移到MVC相对容易；从web表单迁移到MVC更加困难。

我在这里留下一个链接，指向我的一个朋友发表的关于MVP和MVC的一系列文章。

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

不久前，我在博客中引用了托德·斯奈德（Todd Snyder）关于两者区别的精彩文章：

以下是模式：MVP模式视图与模型的耦合更加松散。演示者是负责将模型绑定到视图。更容易进行单元测试，因为与视图的交互是通过的接口通常视图到演示者的映射是一对一。复杂视图可能具有多主持人。MVC模式控制器基于行为，可以在意见可以负责确定要显示的视图

这是我能在网上找到的最好的解释。