在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：控制器负责。

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

MVP=模型视图演示者MVC=模型视图控制器两种演示模式。它们将模型（考虑域对象）、屏幕/网页（视图）和用户界面（演示者/控制器）之间的依赖关系分开它们在概念上相当相似，人们根据口味对演示者/控制器进行不同的初始化。这里有一篇关于差异的精彩文章。最值得注意的是MVC模式具有更新视图的模型。

简而言之，

在MVC中，View有UI部分，它调用控制器，控制器反过来调用模型&模型，然后将事件返回视图。在MVP中，视图包含UI，并调用演示者作为实现部分。演示者直接调用视图以更新UI部分。包含业务逻辑的模型由演示者调用，与视图没有任何交互。因此，演示者完成了大部分工作：）

模型视图控制器

MVC是软件应用程序架构的一种模式。它将应用程序逻辑分为三个独立的部分，促进了模块化和易于协作和重用。它还使应用程序更灵活，更易于迭代。它将应用程序分为以下组件：

处理数据和业务逻辑的模型用于处理用户界面和应用程序的控制器用于处理图形用户界面对象和演示的视图

为了更清楚一点，让我们想象一个简单的购物清单应用程序。我们只需要一份本周需要购买的每件商品的名称、数量和价格的清单。下面我们将描述如何使用MVC实现这些功能。

表示器

模型是将在视图（用户界面）中显示的数据。该视图是一个界面，它显示数据（模型）并将用户命令（事件）发送给演示者，以根据该数据进行操作。视图通常引用其演示者。演示者是“中间人”（由MVC中的控制器扮演），并同时引用视图和模型。请注意，“模型”一词具有误导性。它应该是检索或操纵模型的业务逻辑。例如：如果您有一个数据库将User存储在数据库表中，并且您的View希望显示用户列表，那么Presenter将具有对数据库业务逻辑（如DAO）的引用，Presenter将从中查询用户列表。

如果您想查看具有简单实现的示例，请检查此GitHub帖子

从数据库中查询和显示用户列表的具体工作流可以如下所示：

MVC模式和MVP模式有什么区别？

MVC模式

控制器基于行为，可以跨视图共享可以负责确定要显示的视图（前控制器模式）

MVP模式

视图与模型的耦合更加松散。演示者负责将模型绑定到视图。更容易进行单元测试，因为与视图的交互是通过接口进行的通常视图到演示者的映射是一对一。复杂视图可能有多个演示者。

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

MVC

MVP