最简单的答案是视图如何与模型交互。在MVP中，视图由演示者更新，演示者充当视图和模型之间的中介。演示者从视图中获取输入，视图从模型中检索数据，然后执行所需的任何业务逻辑，然后更新视图。在MVC中，模型直接更新视图，而不是通过控制器返回。

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

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

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

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

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

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

鲍勃叔叔的这段视频很好，他在最后简要解释了MVC和MVP。

IMO，MVP是MVC的一个改进版本，基本上可以将你要显示的内容（数据）与你要显示（视图）的方式分开。演示者包含了UI的某种业务逻辑，隐式地规定了应该显示哪些数据，并为您提供了一个哑视图模型列表。当显示数据时，只需将视图（可能包含相同的id）插入适配器，并使用这些视图模型设置相关的视图字段，只需引入最少的代码（仅使用setter）。它的主要好处是您可以针对许多/各种视图测试UI业务逻辑，例如在水平列表或垂直列表中显示项目。

在MVC中，我们通过接口（边界）来粘合不同的层。控制器是我们体系结构的一个插件，但它对显示内容没有任何限制。从这个意义上讲，MVP是一种MVC，其概念是视图可以通过适配器插入控制器。

我希望这有助于更好。

这两个框架都旨在分离关注点-例如，与数据源（模型）的交互、应用程序逻辑（或将这些数据转换为有用信息）（控制器/演示者）和显示代码（视图）。在某些情况下，模型还可以用于将数据源转换为更高级别的抽象。MVC Storefront项目就是一个很好的例子。

这里讨论了MVC与MVP之间的区别。

所做的区别在于，在MVC应用程序中，视图和控制器传统上与模型交互，而不是彼此交互。

MVP设计让演示者访问模型并与视图交互。

尽管如此，根据这些定义，ASP.NET MVC是MVP框架，因为控制器访问模型以填充视图，这意味着没有逻辑（只显示控制器提供的变量）。

要了解ASP.NET MVC与MVP的区别，请查看Scott Hanselman的MIX演示。