MV* 软件设计架构

软件工程推荐设计高内聚,低耦合的程序,方便代码复用,测试和维护。除了微观上符合 SOLID 原则外,宏观上良好的分层/分类也能极大的降低实体之间的耦合。

客户端应用程序实体可以分成三大类:

  • 模型(Model): 负责数据的更新(CRUD)
  • 视图(View): 负责 UI 的绘制和交互
  • *: 其它实体。负责在 MV 之间传递数据和业务逻辑,常见的抽象有 Controller,Presenter 和 ViewModel 等

根据对其它实体的抽象,出现了一系列 MV* 软件设计架构。本文整理并比较不同设计架构的优缺点和使用场景。

MV

Model-View (MV) 是最简单的一种实现。View 拥有 Model 所有操作权限,负责根据用户输入更新 Model,刷新自己。

MV diagram

优点

  • 代码简单,不需要中间层

缺点

  • Model 和 View 耦合度高,View 负责更新 Model
  • 混有业务逻辑的 View 很难复用

适用场景

  • 简单原型项目
  • View 只读 Model 数据,不更新

MVC

Model-View-Controller (MVC) 是最常见的架构,最原始的实现如下:

MVC diagram

优点

  • 不直接通过 View 更新 Model
  • 使用广泛,有多个变种,针对领域问题有成熟的解决方案
  • 易用性良好

缺点

  • Model 和 View 有绑定,没有完全解耦
  • View 和 Controller 强耦合
  • Controller 可以负责 View 的创建,可避免
  • Controller 负责与 View 交互和业务逻辑,很容易写出臃肿的 Controller。在实际使用时,可将 Controller 进一步拆分。

适用场景

  • 多数客户端项目,保底选择

MVC 有很多变种,比如 Cocoa 的实现:Model 和 View 完全解耦。

Apple MVC diagram

还有一种后端常用的架构,直接从 Controller 开始,到 Render 结束:

Backend MVC diagram

MVP

Model-View-Presenter (MVP) 是 MVC 的另一种演变。把构建 View 的代码从 Controller 中剥离出去(放在 View 中),命名为 Presenter。View 获得用户事件后,把 Event 发给 Presenter 处理。

MVP

优点

  • 不直接通过 View 更新 Model
  • Presenter 不负责 View 的创建
  • Presenter 只负责处理 View 的行为

缺点

  • Presenter 比较薄,导致 Model 和 View 比较重,一般使用 Supervising Controller 给 Model 减负
  • 允许 Model 和 View 有绑定,没有完全解耦

适用场景

  • 一般来说,能使用 MVC 的场景就能使用 MVP

MVVM

Model-View-ViewModel (MVVM) 首次出现在微软的 WPF 和 Silverlight 项目中,是 MVP 的变种。

MVVM diagram

如图所示,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 等多层。

参考资料

如果你喜欢这篇文章,欢迎赞赏作者以示鼓励