当超越RAD（拖放和配置）构建用户界面的方式时，许多工具都鼓励您使用三种设计模式，即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分：
这些模式解决了什么问题？它们有什么相似之处？它们有何不同？
当前回答
MVP=模型视图演示者MVC=模型视图控制器两种演示模式。它们将模型（考虑域对象）、屏幕/网页（视图）和用户界面（演示者/控制器）之间的依赖关系分开它们在概念上相当相似，人们根据口味对演示者/控制器进行不同的初始化。这里有一篇关于差异的精彩文章。最值得注意的是MVC模式具有更新视图的模型。
其他回答
MVP=模型视图演示者MVC=模型视图控制器两种演示模式。它们将模型（考虑域对象）、屏幕/网页（视图）和用户界面（演示者/控制器）之间的依赖关系分开它们在概念上相当相似，人们根据口味对演示者/控制器进行不同的初始化。这里有一篇关于差异的精彩文章。最值得注意的是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
我认为Erwin Vanderwalk的这张图片（以及附带的文章）是对MVC、MVP和MVVM及其相似性和差异的最好解释。这篇文章没有出现在搜索引擎的“MVC、MVP和MVVM”查询结果中，因为文章的标题没有包含“MVC”和“MVP”字样；但我认为这是最好的解释。
（这篇文章也符合鲍勃·马丁大叔在他的一次演讲中所说的：MVC最初是为小型UI组件而设计的，而不是为系统的架构而设计的）
我已经使用了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
我简短的观点是：MVP适用于大范围，MVC适用于小范围。有了MVC，我有时会觉得V和C可能被看作是一个不可分割的组件的两面，而不是直接绑定到M，当向下扩展到较短的规模时，如UI控件和基本控件时，必然会出现这种情况。在这种粒度级别上，MVP意义不大。相反，当一个人走向更大的规模时，适当的界面变得更重要，同样，明确的职责分配也同样重要，MVP就来了。
另一方面，当平台特性有助于组件之间的某种关系时，例如在web上，MVC的实现似乎比MVP更容易。
