MVP：观点是主导的。

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

MVC：控制器负责。

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

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

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

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

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

我认为Erwin Vanderwalk的这张图片（以及附带的文章）是对MVC、MVP和MVVM及其相似性和差异的最好解释。这篇文章没有出现在搜索引擎的“MVC、MVP和MVVM”查询结果中，因为文章的标题没有包含“MVC”和“MVP”字样；但我认为这是最好的解释。

（这篇文章也符合鲍勃·马丁大叔在他的一次演讲中所说的：MVC最初是为小型UI组件而设计的，而不是为系统的架构而设计的）

这两种模式都试图分离表示和业务逻辑，将业务逻辑与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

MVP不一定是视图负责的场景（例如，参见Taligent的MVP）。我觉得很不幸的是，人们仍在宣扬这是一种模式（主管视图），而不是一种反模式，因为它与“这只是一种观点”（实用主义程序员）相矛盾。“这只是一个视图”表示，向用户显示的最终视图是应用程序的次要关注点。微软的MVP模式使视图的重用变得更加困难，并方便地为微软的设计师提供了避免不良做法的借口。

坦率地说，我认为MVC的底层关注点对于任何MVP实现都是正确的，它们之间的差异几乎完全是语义上的。只要您遵循视图（显示数据）、控制器（初始化和控制用户交互）和模型（底层数据和/或服务）之间的关注点分离，就可以实现MVC的好处。如果您正在实现这些好处，那么谁会真正关心您的模式是MVC、MVP还是Supervisory Controller？唯一真正的模式仍然是MVC，其余的只是不同的风格。

考虑一下这篇激动人心的文章，它全面列出了许多不同的实现。你可能会注意到，他们基本上都在做相同的事情，但略有不同。

我个人认为MVP是最近才被重新引入的一个吸引人的术语，目的是为了减少语义偏执者之间的争论，他们争论某些东西是否真正是MVC，或者是为了证明微软的快速应用程序开发工具的合理性。在我的书中，这两个原因都不能证明它是一种独立的设计模式。