MVP：观点是主导的。

在大多数情况下，视图会创建其演示者。演示者将与模型交互并通过界面操纵视图。视图有时会与演示者交互，通常是通过某种界面。这归结于实施；您希望视图调用演示者上的方法，还是希望视图具有演示者侦听的事件？归结起来就是：视图了解演示者。视图将委派给演示者。

MVC：控制器负责。

控制器是根据某些事件/请求创建或访问的。然后，控制器创建适当的视图并与模型交互以进一步配置视图。它归结为：控制器创建和管理视图；视图从属于控制器。视图不知道控制器。

MVC（模型视图控制器）

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

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

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

MVP（模型视图演示者）

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

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

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

MVC与MVP

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

这是对这些设计模式的许多变体的过度简化，但这是我喜欢思考两者之间差异的方式。

MVC

MVP

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

我已经使用了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

这两种模式都试图分离表示和业务逻辑，将业务逻辑与UI方面分离

在架构上，MVP是基于页面控制器的方法，而MVC是基于前端控制器的方法。这意味着MVP标准的web表单页面生命周期只是通过从代码后面提取业务逻辑来增强的。换句话说，page是为http请求提供服务的页面。换句话说，MVP IMHO是一种网络形式的进化型增强。另一方面，MVC完全改变了游戏，因为在加载页面之前，请求被控制器类拦截，在那里执行业务逻辑，然后在控制器处理刚刚转储到页面的数据的最终结果（“视图”）从这个意义上讲，MVC看起来（至少在我看来）很像MVP的Supervisory Controller风格，它通过路由引擎增强了MVP的功能

这两种方法都支持TDD，并有其优缺点。

关于如何选择其中一个IMHO的决定应该基于在ASP.NET web表单类型的web开发中投入的时间。如果有人认为自己擅长网络形式，我会建议MVP。如果你在页面生命周期等方面感觉不太舒服的话，MVC可能是一种方法。

下面是另一个博客文章链接，提供了关于这个主题的更多细节

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx