在MVP中，视图从演示者中提取数据，演示者从模型中提取数据并准备/规范化数据，而在MVC中，控制器通过在视图中推送从模型中获取数据并进行设置。

在MVP中，您可以使用一个视图来处理多种类型的演示者，也可以使用单个演示者来处理不同的多个视图。

MVP通常使用某种绑定框架，例如Microsoft WPF绑定框架或HTML5和Java的各种绑定框架。

在这些框架中，UI/HTML5/XAML知道每个UI元素显示的演示者的属性，因此当您将视图绑定到演示者时，视图会查找财产，并知道如何从中绘制数据，以及当用户在UI中更改值时如何设置这些属性。

因此，例如，如果模型是一辆汽车，那么演示者是某种汽车演示者，向视图公开汽车的财产（年份、制造商、座位等）。视图知道名为“car maker”的文本字段需要显示演示者maker属性。

然后，您可以将许多不同类型的演示者绑定到视图中，所有演示者都必须具有Maker属性-它可以是飞机、火车或其他任何类型的视图，视图都不在乎。视图从演示者（无论是哪一个）获取数据，只要它实现了一个商定的接口。

这个绑定框架，如果你去掉它，它实际上就是控制器：-）

因此，您可以将MVP视为MVC的演变。

MVC很好，但问题是它的控制器通常是每个视图。控制器A知道如何设置视图A的字段。如果现在，您希望视图A显示模型B的数据，您需要控制器A了解模型B，或者需要控制器A接收带有接口的对象，这就像MVP一样，只是没有绑定，或者您需要重写控制器B中的UI设置代码。

结论：MVP和MVC都是UI模式的解耦，但MVP通常使用一个绑定框架，该框架的底层是MVC。THUS MVP的体系结构级别高于MVC，并且是MVC之上的包装模式。

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

MVC（模型视图控制器）

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

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

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

MVP（模型视图演示者）

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

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

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

MVC与MVP

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

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

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

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

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

MVP：观点是主导的。

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

MVC：控制器负责。

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