MVP(SC)、MVP(PV)、PM、MVVM 和 MVC 架构表示模式比较

Shivprasad koirala

4.86/5 (79投票s)

2010年3月18日

CPOL

8分钟阅读

277279

本文将比较四种重要的架构表示模式，即 MVP(SC)、MVP(PV)、PM、MVVM 和 MVC。许多开发人员对这些模式之间的区别以及何时应使用哪种模式感到困惑。本文将首先介绍背景，并解释不同的

引言

本文将比较四种重要的架构表示模式，即 MVP(SC)、MVP(PV)、PM、MVVM 和 MVC。许多开发人员对这些模式之间的区别以及何时应使用哪种模式感到困惑。本文将首先介绍背景，并解释不同类型的表示模式。然后，我们将讨论状态、逻辑和同步问题。最后，我们将详细介绍每种模式，并总结它们之间的区别。

特别感谢

本文全部摘自 https://martinfowler.com.cn/eaaDev/uiArchs.html GUI 架构。Martin Flower 先生的杰出工作。

Josh Smith 和团队 http://msdn.microsoft.com/en-us/magazine/dd419663.aspx ，在 MVVM 方面做了出色的工作。

Nikhil Kothari 先生的博客 http://www.nikhilk.net/Silverlight-ViewModel-Pattern.aspx ，是 MVVM 的绝佳来源。

Oleg Zhukov 先生解释了如何为 .NET 构建 MVP 框架 https://codeproject.org.cn/KB/architecture/DotNetMVPFramework_Part1.aspx

背景 - 表示模式

用户界面面临的最大问题之一是代码混乱。代码混乱主要有两个原因：一是 UI 包含复杂的逻辑来操作用户界面对象，二是 UI 还维护着应用程序的状态。表示模式旨在如何消除 UI 的复杂性，使其更清晰、更易于管理。下面根据下图所示，列出了不同种类和分类的表示模式。

表示模式分为三个重要类别：MVP（Model View Presenter）、MVC（Model View Controller）以及 PM（Presenter Model）。MVP 又分为 Supervising Controller 和 Passive View。Presenter Model 又被微软团队细分为两种特定于技术的模式：MVVM for Silverlight 和 MVVM for WPF。

UI 的 3 大问题：状态、逻辑和同步

UI 存在以下 3 个主要问题：

状态：状态/数据是 UI 中最大的关注点之一。状态表示用户界面的当前数据图景。在 Web 术语中，它可以是会话变量；在 Windows 应用程序中，它可以是简单的 UI 级数据。UI 维护的状态越多，复杂性就越高。

逻辑：用户界面通常包含 UI 逻辑，如操作文本框、组合框或其他 UI 元素。这些逻辑存在于 UI 中越多，UI 就越复杂。

同步：用户界面通常与域/业务组件进行协调。UI 还需要在 UI 元素（文本框、组合框等）和业务对象之间同步数据。如果 UI 负责同步，UI 的复杂性就会增加。

英雄 - 表示设计模式

表示设计模式有助于解决上述 UI 问题。表示设计模式的基本原理是，我们需要创建一个额外的类来处理目前由 UI 承担的复杂逻辑、数据和同步问题，从而使 UI 变得简单、干净。这个类承担责任的程度决定了它是 SC、PV、PM 设计模式还是其他。换句话说，表示器的成熟度决定了它的设计模式类型。

一些简化文章的缩写

缩写	全称
V	视图或用户界面。
P	包含 UI 逻辑的 Presenter 类。
L	UI 逻辑
S	UI 的状态
M	业务组件或域对象。
SC	Supervising controller（监督控制器）。
PV	Passive view（被动视图）。
PM	Presenter model（表示器模型）。

我们将使用上述缩写来简化表示设计模式的解释。

Supervising controller 模式 (SC)

SC 的基本原理：

状态存储在视图中。
Presenter 拥有复杂的表示逻辑。简单的 UI 绑定逻辑通过 WPF 绑定和 Silverlight 绑定等绑定技术进行处理。任何复杂的逻辑都由 presenter 类处理。
Presenter 知道视图。
视图不知道 presenter。
视图使用 WPF 和 Silverlight 提供的技术绑定与模型连接。

Passive view (PV)

PV 的基本原理：

状态存储在视图中。
UI 的所有逻辑都存储在 presenter 中。
视图与模型完全隔离。它还负责在模型和视图之间同步数据。
Presenter 知道视图。
视图不知道 presenter。

你可以从这里阅读更多关于 MVP (PV) 的信息，其中还包含一个演示 MVP 如何工作的示例代码：链接

Presentation Model (PM)

SC 的基本原理：

状态存储在 presenter 中。
逻辑存储在 presenter 中。
Presenter 表示 UI 的抽象视图。
Presenter 不知道视图。
视图知道 presenter。
视图与模型完全隔离。

MVVM

SC 的基本原理：

Presenter model 是基础。
状态存储在 presenter 中。
逻辑存储在 presenter 中。
Presenter 表示 UI 的抽象视图。
Presenter 不知道视图。
视图知道 presenter。
视图与模型完全隔离。
使用 WPF 和 Silverlight 绑定。

MVC

MVC 的基本原理：

没有 presenter，只有 controller。
请求首先到达 controller。
Controller 将模型与视图绑定。
逻辑存储在 controller 中。

你可以从这里阅读更多关于 MVC 的信息，其中还包含一个演示 MVC 如何工作的示例代码：链接

总结

下面是一个从状态、逻辑和同步的角度对所有表示模式进行的总结比较表。

		状态	逻辑	同步
Supervising controller
	表示器		X	X
	视图	X
	模型	视图使用 WPF 绑定、Silverlight 绑定等数据绑定连接到模型获取数据。
Passive View
	表示器		X	X
	视图	X
Presenter model
	表示器	X	X
	视图			X
MVVM
	表示器	X	X
	视图			X
	使用 WPF、Silverlight、ASP.NET 的数据绑定命令。
MVC	控制器 (Controller)		X	X
	视图	X

下面是我们上面讨论内容的视觉比较。

何时使用 MVP？何时使用 MVC？

首先，所有上述模式都是 MVC 的变体。换句话说，所有 MVP 模式都是 MVC 的变体。我们将首先比较 MVC 和 MVP，然后比较 MVP 的不同变体。

以下是 MVP 相较于 MVC 的优势情况。

UI 单元测试：如果您的项目更加注重 UI 的自动化单元测试，那么 MVP 相较于 MVC 是更优的选择，因为 MVP 的 presenter 类将所有 UI 逻辑隔离到 presenter 中。Presenter 是 UI 的完整模拟，因此可以使用 VSTS Test Suite 或 NUNIT 单独进行单元测试。

视图相同但略有差异：如果您的应用程序性质是视图可以重用但数据略有不同，那么 MVC 是一个不错的选择。特别是如果您有一个更偏向报表性质的应用程序。例如，有两个几乎相同的视图，如“按月销售”和“按年销售”。这两个报表都可以通过使用相同的 ASPX 页面显示，可能带有不同的模型。因此，如果您的应用程序具有相同的 UI 外观和感觉，但略有不同，MVC 是一个很好的选择。特别是如果您有一个报表性质的应用程序，MVC 相较于 MVP 会运行得更快。

多 UI 支持：如果您预计您的应用程序将消耗不同的 UI 技术，那么 MVP 是一个不错的选择。换句话说，如果您的应用程序将由 Windows UI 和 Web 应用程序 UI 使用，那么 MVP 是一个不错的选择。它将通过使用 presenter 类来帮助您提高可重用性。

复杂屏幕：如果您有具有大量用户交互的复杂屏幕，MVC 可能会很复杂，因为您最终会为每次交互创建大量 controller 类。MVP 在这里更适合，因为您可以将这些复杂的逻辑封装到一个类中，并单独测试它以确保代码没有错误。

使用的技术：技术是一个非常重要的因素。如果技术为架构构建提供了自动化，那么使用相应的模式就更有意义了。例如，如果您纯粹使用 ASP.NET 应用程序，而不使用 Silverlight 或 WPF，那么选择 MVP 会更合理。ASP.NET 页面期望在后台代码中处理控件事件，而 MVC 期望在 controller 中处理这些事件。因此，我们最终会在 controller 中重写 ASP.NET 控件的完整事件处理代码。如果您使用 Silverlight 和 WPF，它们具有良好的绑定支持，这使得 MVP 更为适合。另一方面，如果您的视图相同但略有差异，并且您使用的是 3.5 框架，您可以使用 MVC 框架来自动化并满足您的需求。

技术选择决定了您选择 MVC 还是 MVP 的 60%。

何时使用 SC、PV、PM 和 MVVM？

即将推出。