当超越RAD（拖放和配置）构建用户界面的方式时，许多工具都鼓励您使用三种设计模式，即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分：
这些模式解决了什么问题？它们有什么相似之处？它们有何不同？
当前回答
我简短的观点是：MVP适用于大范围，MVC适用于小范围。有了MVC，我有时会觉得V和C可能被看作是一个不可分割的组件的两面，而不是直接绑定到M，当向下扩展到较短的规模时，如UI控件和基本控件时，必然会出现这种情况。在这种粒度级别上，MVP意义不大。相反，当一个人走向更大的规模时，适当的界面变得更重要，同样，明确的职责分配也同样重要，MVP就来了。
另一方面，当平台特性有助于组件之间的某种关系时，例如在web上，MVC的实现似乎比MVP更容易。
其他回答
同样值得记住的是，MVP也有不同的类型。福勒将这种模式分为两种：被动视图和监督控制器。
使用被动视图时，视图通常实现一个细粒度的接口，其中财产或多或少直接映射到底层UI小部件。例如，您可能有一个具有诸如Name和Address等财产的ICustomerView。
您的实现可能如下所示：
public class CustomerView : ICustomerView
{
public string Name
{
get { return txtName.Text; }
set { txtName.Text = value; }
}
}
Presenter类将与模型对话，并将其“映射”到视图。这种方法被称为“被动视图”。好处是视图易于测试，并且更容易在UI平台（Web、Windows/XML等）之间移动。缺点是无法利用数据绑定（在WPF和Silverlight等框架中，数据绑定功能非常强大）。
MVP的第二个特点是监督控制员。在这种情况下，您的View可能有一个名为Customer的属性，然后该属性再次绑定到UI小部件。您不必考虑同步和微观管理视图，监督控制器可以在需要时介入并提供帮助，例如使用复杂的交互逻辑。
MVP的第三个“味道”（或者有人可能会称之为一个单独的模式）是演示模型（或者有时称为模型-视图-视图模型）。与MVP相比，你将M和P“合并”为一个类。您有UI小部件数据绑定到的客户对象，但也有其他UI特定字段，如“IsButtonEnabled”或“IsReadOnly”等。
我认为我找到的最好的UI架构资源是Jeremy Miller在the Build Your Own CAB系列目录上发表的一系列博客文章。他涵盖了MVP的所有风格，并展示了实现它们的C#代码。
我也在YouCard网站上写过关于Silverlight上下文中的模型-视图-视图-模型模式的博客。
这是对这些设计模式的许多变体的过度简化，但这是我喜欢思考两者之间差异的方式。
MVC
MVP
MVP=模型视图演示者MVC=模型视图控制器两种演示模式。它们将模型（考虑域对象）、屏幕/网页（视图）和用户界面（演示者/控制器）之间的依赖关系分开它们在概念上相当相似，人们根据口味对演示者/控制器进行不同的初始化。这里有一篇关于差异的精彩文章。最值得注意的是MVC模式具有更新视图的模型。
我简短的观点是：MVP适用于大范围，MVC适用于小范围。有了MVC，我有时会觉得V和C可能被看作是一个不可分割的组件的两面，而不是直接绑定到M，当向下扩展到较短的规模时，如UI控件和基本控件时，必然会出现这种情况。在这种粒度级别上，MVP意义不大。相反，当一个人走向更大的规模时，适当的界面变得更重要，同样，明确的职责分配也同样重要，MVP就来了。
另一方面，当平台特性有助于组件之间的某种关系时，例如在web上，MVC的实现似乎比MVP更容易。
我认为Erwin Vanderwalk的这张图片（以及附带的文章）是对MVC、MVP和MVVM及其相似性和差异的最好解释。这篇文章没有出现在搜索引擎的“MVC、MVP和MVVM”查询结果中，因为文章的标题没有包含“MVC”和“MVP”字样；但我认为这是最好的解释。
（这篇文章也符合鲍勃·马丁大叔在他的一次演讲中所说的：MVC最初是为小型UI组件而设计的，而不是为系统的架构而设计的）
