表示器

在MVP中，演示者包含视图的UI业务逻辑。视图中的所有调用都直接委派给演示者。演示者也直接与视图分离，并通过接口与视图对话。这是为了允许在单元测试中模拟视图。MVP的一个共同特点是必须有很多双向调度。例如，当有人单击“保存”按钮时，事件处理程序将委托给演示者的“OnSave”方法。保存完成后，演示者将通过其界面调用视图，以便视图显示保存已完成。

MVP往往是在WebForms中实现分离表示的一种非常自然的模式。原因是视图总是首先由ASP.NET运行时创建。您可以了解更多关于这两种变体的信息。

两种主要变化

被动视图：视图尽可能地哑，几乎包含零逻辑。演示者是与视图和模型对话的中间人。视图和模型彼此完全屏蔽。模型可能会引发事件，但演示者会订阅这些事件以更新视图。在被动视图中，没有直接的数据绑定，相反，视图公开了演示者用于设置数据的setter财产。所有状态都在演示者中管理，而不是在视图中管理。

Pro：最大可测试表面；视图和模型的清晰分离缺点：更多的工作（例如所有setter财产），因为您正在自己进行所有数据绑定。

监督控制器：演示者处理用户手势。视图通过数据绑定直接绑定到模型。在这种情况下，演示者的工作是将模型传递给视图，以便它可以绑定到它。演示者还将包含诸如按下按钮、导航等手势的逻辑。

优点：通过利用数据绑定，减少了代码量。缺点：有一个不太可测试的表面（因为数据绑定），并且视图中的封装更少，因为它直接与模型对话。

模型视图控制器

在MVC中，控制器负责确定响应于任何操作（包括应用程序加载时）显示哪个视图。这与MVP不同，MVP将动作通过视图传递到演示者。在MVC中，视图中的每个动作都与对Controller的调用以及动作相关。在网络中，每个动作都涉及到对URL的调用，URL的另一端有一个控制器进行响应。控制器完成处理后，将返回正确的视图。该序列在应用程序的整个生命周期中以这种方式继续：

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

MVC的另一个重要区别是视图不直接绑定到模型。该视图只是呈现，完全无状态。在MVC的实现中，视图通常在代码后面没有任何逻辑。这与MVP相反，MVP是绝对必要的，因为如果视图不委托给演示者，它将永远不会被调用。

演示模型

另一种模式是演示模型模式。在此模式中，没有演示者。相反，视图直接绑定到演示模型。演示模型是专门为视图设计的模型。这意味着该模型可以公开人们永远不会放在域模型上的财产，因为这将违反关注分离。在这种情况下，表示模型绑定到域模型，并可以订阅来自该模型的事件。然后，视图订阅来自演示模型的事件，并相应地更新自己。表示模型可以公开视图用于调用操作的命令。这种方法的优点是，当PM完全封装了视图的所有行为时，您基本上可以完全删除代码。这种模式非常适合在WPF应用程序中使用，也称为模型视图视图模型。

MSDN上有一篇关于演示模型的文章，WPF（前Prism）的复合应用指南中有一节关于分离的演示模式

模型视图控制器

MVC是软件应用程序架构的一种模式。它将应用程序逻辑分为三个独立的部分，促进了模块化和易于协作和重用。它还使应用程序更灵活，更易于迭代。它将应用程序分为以下组件：

处理数据和业务逻辑的模型用于处理用户界面和应用程序的控制器用于处理图形用户界面对象和演示的视图

为了更清楚一点，让我们想象一个简单的购物清单应用程序。我们只需要一份本周需要购买的每件商品的名称、数量和价格的清单。下面我们将描述如何使用MVC实现这些功能。

表示器

模型是将在视图（用户界面）中显示的数据。该视图是一个界面，它显示数据（模型）并将用户命令（事件）发送给演示者，以根据该数据进行操作。视图通常引用其演示者。演示者是“中间人”（由MVC中的控制器扮演），并同时引用视图和模型。请注意，“模型”一词具有误导性。它应该是检索或操纵模型的业务逻辑。例如：如果您有一个数据库将User存储在数据库表中，并且您的View希望显示用户列表，那么Presenter将具有对数据库业务逻辑（如DAO）的引用，Presenter将从中查询用户列表。

如果您想查看具有简单实现的示例，请检查此GitHub帖子

从数据库中查询和显示用户列表的具体工作流可以如下所示：

MVC模式和MVP模式有什么区别？

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上下文中的模型-视图-视图-模型模式的博客。

我已经使用了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（模型视图控制器）

在MVC中，控制器是负责人！控制器根据一些事件/请求触发或访问，然后管理视图。

MVC中的视图实际上是无状态的，控制器负责选择要显示的视图。

例如：当用户单击“Show MyProfile”（显示我的配置文件）按钮时，将触发控制器。它与模型通信以获得适当的数据。然后，它会显示一个类似于配置文件页面的新视图。控制器可以从模型中获取数据并将其直接馈送到视图（如上图所示），或者让视图从模型本身获取数据。

MVP（模型视图演示者）

在MVP中，视图是负责人！每个视图都会调用其演示者或演示者收听的某些事件。

MVP中的视图不实现任何逻辑，演示者负责实现所有逻辑，并使用某种接口与视图进行通信。

例如：当用户单击“保存”按钮时，视图中的事件处理程序将委派给演示者的“OnSave”方法。演示者将执行所需的逻辑，并与模型进行任何所需的通信，然后通过其界面调用视图，以便视图显示保存已完成。

MVC与MVP

MVC并没有让视图负责，视图充当控制器可以管理和指导的从属对象。在MVC中，视图是无状态的，而MVP中的视图是有状态的，可以随时间变化。在MVP中，视图没有逻辑，我们应该尽可能让它们保持沉默。另一方面，MVC中的视图可能有某种逻辑。在MVP中，演示者与视图分离，并通过接口与视图对话。这允许在单元测试中模拟视图。在MVP中，视图与模型完全隔离。然而，在MVC中，视图可以与模型通信，以使其与最新的最新数据。

你忘了动作域响应程序（ADR）。

正如上面的一些图形所解释的，MVC中的模型和视图之间有直接的关系/链接。在控制器上执行操作，控制器将在模型上执行操作。模型中的该操作将触发视图中的反应。视图在模型状态更改时始终更新。

有些人一直忘记了，MVC是在70年代末创建的，而Web只是在80年代末/90年代初创建的。MVC最初不是为Web创建的，而是为桌面应用程序创建的，其中Controller、Model和View将共存。

因为我们使用的是仍然使用相同命名约定（模型-视图-控制器）的web框架（例如：.Laravel），所以我们倾向于认为它必须是MVC，但实际上是其他东西。

相反，请查看操作域响应程序。在ADR中，控制器获得一个动作，该动作将在模型/域中执行操作。到目前为止，情况是一样的。不同的是，它然后收集该操作的响应/数据，并将其传递给Responder（例如：.view（））进行渲染。当在同一组件上请求新操作时，将再次调用Controller，并重复循环。在ADR中，模型/域和视图（Reposer的响应）之间没有任何联系。

注意：维基百科指出“然而，每个ADR动作都由单独的类或闭包表示”。这不一定是真的。多个操作可以在同一控制器中，并且模式仍然相同。

mvc adr模型视图控制器动作域响应器