这个问题有很多答案，但我觉得需要一些非常简单的答案来清楚地比较两者。以下是我在用户在MVP和MVC应用程序中搜索电影名称时所做的讨论：

用户：单击…

观点：那是谁？[MVP|MVC]

用户：我刚刚点击了搜索按钮…

视图：好的，等一下。[MVP|MVC]

（视图调用演示者|控制器…）[MMVP|MVC]

视图：嗨，演示者|控制器，用户刚刚单击了搜索按钮，我该怎么办？[MVP|MVC]

演示者|控制器：嘿，View，那个页面上有搜索词吗？[MVP|MVC]

视图：是的，…这里是…“钢琴”[MMVP|MVC]

演示者|控制器：谢谢查看，……同时我正在查找模型上的搜索项，请向他/她显示进度条[MVP|MVC]

（演示者|控制器正在调用模型…）[MMVP|MVC]

演示者|控制器：嘿，模特儿，你有匹配这个搜索词的吗？：“钢琴”[MVP|MVC]

模型：嘿，演示者|控制器，让我检查一下…〔MVP|MVC〕

（模型正在对电影数据库进行查询…）[MVP|MVC]

（过了一会儿…）

--------------这就是MVP和MVC开始分化的地方---------------

模型：我为您找到了一个列表，演示者，这里是JSON格式的“[{“name”：“Piano Teacher”，“year”：2001}，{“name:”Piano”，“year”：1993}]”[MVP]

模型：有一些结果可用，控制器。我在实例中创建了一个字段变量，并用结果填充它。它的名称是“searchResultsList”[MVC]

（演示者|控制器感谢模型并返回视图）[MMVP|MVC]

演示者：感谢等待View，我为您找到了一个匹配结果列表，并以可呈现的格式排列：[“Piano Teacher 2001”，“Piano 1993”]。请在垂直列表中向用户显示。也请现在隐藏进度条[MMVP]

控制器：感谢等待View，我已经向Model询问了您的搜索查询。它说它找到了一个匹配结果的列表，并将它们存储在其实例中名为“searchResultsList”的变量中。你可以从那里得到它。也请立即隐藏进度条[MVC]

观点：非常感谢演示者MVP

视图：谢谢“控制器”[MVC]（现在，视图正在质疑自己：我应该如何向用户展示我从模型中获得的结果？电影的制作年份应该是第一年还是最后一年……？它应该在垂直列表还是水平列表中？…）

如果你感兴趣的话，我一直在写一系列关于应用程序架构模式（MVC、MVP、MVVP、干净架构……）的文章，并在这里附上Github repo。尽管该示例是为android编写的，但其基本原理可以应用于任何介质。

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

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

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

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

在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之上的包装模式。

MVC有很多版本，这个答案是关于Smalltalk中的原始MVC。简而言之，它是

本期演讲droidcon NYC 2017-带有架构组件的干净应用程序设计阐明了这一点

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

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

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

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

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

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

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

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

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