架构模式：MVC、MVP 与 MVVM
2024 年 2 月 3 日
当我们讨论软件设计中的架构模式时，最常被提到的往往是客户端-服务端、分层架构、单体架构、微内核架构、事件驱动架构等。这些模式关注的是整体系统架构，通常涉及多个应用、服务和服务器。
不过，MVC、MVP 和 MVVM 更关注如何在单个应用内部组织代码。它们通过分离数据、用户界面和逻辑来管理复杂度，可以看作是架构模式中更偏应用内部结构的一类。
MVC、MVP 与 MVVM
为了让文章保持可读，也避免篇幅过长，本文只关注用于组织单个应用代码的三种架构模式：
- 模型-视图-控制器
- 模型-视图-表示器
- 模型-视图-视图模型
很明显，这三种模式都有两个固定组成部分：模型和视图。因此在分别介绍这些架构之前，我们先了解这两层。
模型
模型包含软件中所有与数据相关的代码。它负责让数据库层、网络层与应用的其他部分进行通信。它的主要职责包括：
- 处理数据和业务逻辑。
- 封装应用数据，以及访问这些数据的规则。
- 管理数据结构。
- 对数据执行增删改查操作。
视图
视图基本上就是应用的前端，也就是用户可以看到并与之交互的部分。它通常也被称为应用的用户界面。它的职责包括：
- 处理非业务逻辑和纯展示逻辑。
- 将其他层提供的数据呈现给用户。
- 接收用户输入，并把输入转发给其他层。
- 视具体架构而定，可能会或不会直接与模型层通信。
模型-视图-控制器（MVC）架构
现在我们已经理解了模型和视图层的职责，接下来看看具体的架构模式。
从 MVC 开始。MVC 使用控制器层同时与模型层和视图层通信。
控制器的主要职责包括：
- 通过模型层操作数据。
- 从视图层接收用户操作或界面指令。
- 根据控制逻辑产生的变化更新视图。
在 MVC 中，视图层虽然不能直接操作模型层，但可以基于数据变化接收更新。因此三层之间以某种形式互相关联，其中控制器是主要协调组件。
模型-视图-表示器（MVP）架构
在 MVP 中，表示器层承担模型层和视图层之间“中间人”的职责，负责处理它们之间的全部通信。模型层与视图层之间没有直接通信。
它的职责包括：
- 根据用户操作更新用户界面或视图层。
- 根据代码逻辑更新数据或模型层。
- 处理大量原本在 MVC 控制器中承担的业务逻辑。
模型-视图-视图模型（MVVM）架构
乍看之下，MVVM 与 MVP 非常相似，但两者之间仍然有一些关键差异：
- 多个视图可以映射到同一个视图模型层。
- 它使用视图模型层与视图层之间的数据绑定，因此更偏事件驱动。
- 在这个架构中没有“用户界面”这一单独概念。视图层代表的是用户行为，而不是界面本身。
总结
本文介绍了几种架构模式的基础：从整体架构如何设计，到单个应用如何进一步划分为三个组件，从而获得更好的管理能力和可扩展性。
- MVC 方式直接，仍然广泛用于 Web 应用。
- MVP 建立在 MVC 基础上，提供更好的可测试性和更清晰的关注点分离。
- MVVM 是三者中较新的模式，在现代应用开发中获得了很高的采用度。
它们之间没有绝对胜者。每一种模式都有自己的优势，适用于不同项目和开发场景。随着软件开发继续演进，我们可能还会看到这些模式被进一步改进，或者出现新的架构方式。