MV* 软件设计架构
软件工程推荐设计高内聚，低耦合的程序，方便代码复用，测试和维护。除了微观上符合 SOLID 原则外，宏观上良好的分层/分类也能极大的降低实体之间的耦合。
客户端应用程序实体可以分成三大类：
- 模型(Model): 负责数据的更新(CRUD)
- 视图(View): 负责 UI 的绘制和交互
- *: 其它实体。负责在 MV 之间传递数据和业务逻辑，常见的抽象有 Controller，Presenter 和 ViewModel 等
根据对其它实体的抽象，出现了一系列 MV* 软件设计架构。本文整理并比较不同设计架构的优缺点和使用场景。
MV
Model-View (MV) 是最简单的一种实现。View 拥有 Model 所有操作权限，负责根据用户输入更新 Model，刷新自己。
优点
- 代码简单，不需要中间层
缺点
- Model 和 View 耦合度高，View 负责更新 Model
- 混有业务逻辑的 View 很难复用
适用场景
- 简单原型项目
- View 只读 Model 数据，不更新
MVC
Model-View-Controller (MVC) 是最常用的架构，最原始的实现如下：
优点
- 不直接通过 View 更新 Model
- 使用广泛，被多次工程实践所验证。有多个变种，针对领域问题有成熟的解决方案
- 易用性良好
缺点
- Model 和 View 有绑定，没有完全解耦
- View 和 Controller 强耦合
- Controller 可以负责 View 的创建，可避免
- Controller 负责与 View 交互和业务逻辑，很容易写出臃肿的 Controller。在实际使用时，可将 Controller 进一步拆分。
适用场景
- 多数项目，保底选择
MVC 有很多变种，比如 Cocoa 的实现：Model 和 View 完全解耦。
还有一种后端常用的架构，直接从 Controller 开始，到 Render 结束：
MVP
Model-View-Presenter (MVP) 是 MVC 的另一种演变。把构建 View 的代码从 Controller 中剥离出去(放在 View 中)，命名为 Presenter。View 获得用户事件后，把 Event 发给 Presenter 处理。Presenter 通常使用接口（interface）与 View 通信，只负责处理 View 中的用户交互事件，不涉及视图逻辑（比如：状态管理和数据绑定等高级功能）。
优点
- 不直接通过 View 更新 Model
- Presenter 不负责 View 的创建
- Presenter 只负责处理 View 的行为，不负责 View 的状态管理
缺点
- Presenter 比较薄，导致 Model 和 View 比较重，一般使用 Supervising Controller 给 Model 减负
- 允许 Model 和 View 有绑定，没有完全解耦
- View 仍然包含状态管理、数据绑定等逻辑
适用场景
- 一般来说，能使用 MVC 的场景就能使用 MVP
MVVM
Model-View-ViewModel (MVVM) 首次出现在微软的 WPF 和 Silverlight 项目中，是 MVP 的变种。
如图所示，MVVM 和 Cocoa MVC 的实现非常接近，不同之处在于：Cocoa MVC 版本中的 View Controller 除了负责业务逻辑外，还负责创建 UI，和 View 的耦合更紧密。而 MVVM 中的 ViewModel 不创建任何 UI，只封装与 UI 相关的状态。ViewModel 相比于 ViewController 更加轻量。
MVVM 会利用绑定技术，View 变化时，ViewModel 会自动变化，反之亦然。所以，MVVM 模式又被称作：model-view-binder 模式。
优点
- Model 和 View 彻底解耦
- ViewModel 只负责 View 状态的改变，不创建 UI
- 业务逻辑独立于 Model 和 View，可单独测试
缺点
- 数据绑定使得 Bug 很难被调试
- 对于过大的项目，数据绑定和数据转化需要花费更多的内存（成本）
- 给每个 View 设置一个 ViewModel 会增加代码量
适用场景
- 对数据绑定友好支持的平台/项目
- 高模块化应用
比较和总结
据我理解，MV* 架构的不同点体现在 Controller, Presenter, ViewModel 的职责和与 MV 的协作方式上。比较如下：
| 职责 | 与 MV 的协作方式 | |
|---|---|---|
| Controller | 操作数据并控制 View | 在 MV 中占主导地位，同时控制 MV |
| Presenter | 负责响应 View 的行为 | 连接 Model 和 View |
| ViewModel | 负责 View 的状态 并响应 View 的行为 | 和 View 强(弱)绑定 |
在实际使用时，并不单一使用某一种架构。也不只分成三层，可以构建 Service，Storage，NetworkRequest 等多层。
参考资料
- iOS Architecture Patterns
- GUI Architectures: MVP
- SwiftUI Architectures: Model-View, Redux & MVVM
- Migrating Swift iOS Apps from MVC to MVVM
- Ending the debate: MVC vs MVP vs MVVM for iOS application development
- MVC vs MVVM: Key Differences with Examples
- 浅谈 MVC、MVP 和 MVVM 架构模式
如果你喜欢这篇文章，欢迎赞赏作者以示鼓励
