MVC（模型视图控制器）

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

MVP（模型视图演示者）

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

更多参考信息

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

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

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

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

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

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

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

MVC

MVP

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

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

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

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

同样值得记住的是，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上下文中的模型-视图-视图-模型模式的博客。

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

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