MVP和MVC有什么区别？

问题描述

模型视图展示者

在，Presenter包含视图的UI业务逻辑。View委托的所有调用均直接传递给Presenter。演示者也直接从视图中分离出来，并通过界面与之对话。这是为了在单元测试中模拟View。MVP的一个共同属性是必须有很多双向分配。例如，当有人单击“保存”按钮时，事件处理程序将委托给演示者的“ OnSave”方法。销售完成后，演示者将通过其界面回调视图，以便视图可以显示保存已完成。

MVP往往是在WebForms中实现独立表示的一种非常自然的模式。原因是View总是首先由ASP.NET运行时创建。您可以找到有关这两种变体的更多信息。

两个主要变化

视图尽可能愚蠢，并且包含几乎为零的逻辑。演示者是与视图和模型对话的中间人。视图和模型完全相互屏蔽。模型可以引发事件，但是演示者订阅了这些事件以更新视图。在Passive View中，没有直接的数据绑定，相反，该View公开了Presenter用于设置数据的setter属性。所有状态都在Presenter中管理，而不是在View中管理。

优点：最大的可测试性表面；视图和模型的清晰分离
缺点：在自己进行所有数据绑定时，需要做更多的工作（例如，所有的setter属性）。

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

优点：通过利用数据绑定，减少了代码量。
缺点：由于数据绑定，可测试的表面较少，并且由于视图直接与模型对话，因此视图中的封装较少。

模型视图控制器

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

    视图中的操作
        ->呼叫控制器
        ->控制器逻辑
        ->控制器返回视图。

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

展示模型

另一个要看的模式是模式。在这种模式下，没有演示者。而是，视图直接绑定到演示模型。Presentation Model是专门为View设计的模型。这意味着此模型可以公开一个永远不会放在域模型上的属性，因为这将违反关注点分离。在这种情况下，表示模型绑定到域模型，并且可以订阅来自该模型的事件。然后，View订阅来自Presentation Model的事件并相应地更新自身。Presentation Model可以公开视图用于调用动作的命令。这种方法的优点是，由于PM完全封装了视图的所有行为，因此您基本上可以完全删除后面的代码。模型-视图- 视图模型。

在MSDN上有关于演示模型的文章，在 WPF（前棱镜）的复合应用指南中有关于单独的演示模式的部分

解决方法

想要改善这篇文章吗？ 提供此问题的详细答案，包括引文和答案正确的解释。答案不够详细的答案可能会被编辑或删除。

当超越RAD（拖放和配置）构建用户界面的方式时，许多工具鼓励您使用三种设计模式，分别称为Model-
View-
Controller，Model-
View-
Presenter和Model-
View-ViewModel。我的问题包括三个部分：

这些模式解决了哪些问题？
它们有何相似之处？
它们有何不同？

design-pattern