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

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

简而言之，

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

MVP

MVP代表模型-视图-演示者。2007年初，微软推出了Smart Client windows应用程序。

演示者在MVP中充当监督角色，MVP绑定模型中的视图事件和业务逻辑。

视图事件绑定将从视图界面在Presenter中实现。

视图是用户输入的发起者，然后将事件委派给演示者，演示者处理事件绑定并从模型中获取数据。

赞成的意见：视图只有UI，没有任何逻辑高水平的可测试性

欺骗：实现事件绑定时有点复杂，工作量更大

MVC

MVC代表模型视图控制器。控制器负责创建模型并使用绑定模型渲染视图。

控制器是启动器，它决定渲染哪个视图。

赞成的意见：强调单一责任原则高水平的可测试性

欺骗：如果试图在同一控制器中渲染多个视图，有时控制器的工作量太大。

我简短的观点是：MVP适用于大范围，MVC适用于小范围。有了MVC，我有时会觉得V和C可能被看作是一个不可分割的组件的两面，而不是直接绑定到M，当向下扩展到较短的规模时，如UI控件和基本控件时，必然会出现这种情况。在这种粒度级别上，MVP意义不大。相反，当一个人走向更大的规模时，适当的界面变得更重要，同样，明确的职责分配也同样重要，MVP就来了。

另一方面，当平台特性有助于组件之间的某种关系时，例如在web上，MVC的实现似乎比MVP更容易。

我已经使用了MVP和MVC，尽管我们作为开发人员倾向于关注这两种模式的技术差异，但IMHO中MVP的要点与易于采用性比其他任何东西都更相关。

如果我所在的团队已经具备良好的web表单开发风格背景，那么引入MVP比引入MVC要容易得多。我认为MVP在这种情况下是一场快速的胜利。

我的经验告诉我，将团队从web表单转移到MVP，然后从MVP转移到MVC相对容易；从web表单迁移到MVC更加困难。

我在这里留下一个链接，指向我的一个朋友发表的关于MVP和MVC的一系列文章。

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

MVC（模型视图控制器）

输入首先指向控制器，而不是视图。该输入可能来自与页面交互的用户，但也可能来自简单地在浏览器中输入特定的url。在任何一种情况下，它都是一个控制器，与之接口以启动某些功能。控制器和视图之间存在多对一关系。这是因为单个控制器可以基于正在执行的操作选择要渲染的不同视图。注意从控制器到视图的单向箭头。这是因为视图对控制器没有任何了解或参考。控制器确实会传递回模型，因此视图和传递给它的预期模型之间存在知识，而不是提供服务的控制器。

MVP（模型视图演示者）

输入以视图开始，而不是演示者。视图和关联的演示者之间有一对一的映射。视图包含对演示者的引用。演示者也会对从视图触发的事件做出反应，从而了解与其关联的视图。演示者根据对模型执行的请求操作更新视图，但视图不支持模型。

更多参考信息