六 软件架构MVC架构历史

一、引子一个系统可能由很多子系统组成 。各子系统内部高度内聚,子系统之间低耦合 。子系统关注自己的职责 。实现:   职责分离,关注点分离 。----MVC架构早期就是为了分离视图、模型而诞生的 。
注:很多地方说MVC是一种设计模式 , 博主认为 , 精确来说MVC是一种架构模式(软件架构(三)名词解释:架构、设计、风格、模式) , 一种通用设计方案,发展至今,已不局限于前端或后端 。例如springMVC就是其中一种落地实践 。
二、MVC的发展史MVC有很多变种,这里列出对现在行业影响最大的几种 , 逐一说明 。老司机可以直接跳到第三节 。
2.1 MVC(Model-View-Controller)

六 软件架构MVC架构历史

文章插图
Trygve Reenskaug 于1979 年提出了 MVC 模式,来分离关注点 , 将 UI 和业务逻辑隔离 。
MVC 模式将代码拆分成了三个概念单元:
  • Model (模型):代表业务逻辑 ;
  • View (视图):代表 UI 控件,按钮、文本框等等;
  • Controller(控制器):在视图和模型之间居中协调,这意味着:
    • 它决定显示哪些视图以及哪些数据;
    • 它将用户操作(例如点击按钮)转换成业务逻辑 。
最初的 MVC 模式还有其它一些需要了解的的重要概念:
  1. View 直接使用 Model 数据对象来展示数据;
  2. 当 Model 发生变化时,会触发一个事件立即更新 View(记?。?1979年还没有 HTTP);
  3. 每一个 View 通常只关联一个 Controller;
  4. 每个界面可以包含多对 View 和 Controller;
  5. 每个Controller 可以对应多个 View 。
2.2 MVP(Model-View-Presenter)
六 软件架构MVC架构历史

文章插图
1996 年,IBM 的子公司 Taligent 公开了他们基于 MVC 的 模式 MVP 。其思想是将 Model 对 UI 的关注更彻底地分离:
  • View 是被动的,对 Model 无感知;
  • 专注于轻量 Controller(Presenter) , 它们不包含任何业务逻辑,只是简单地调用命令/查询模型,将原始数据传递给 View;
  • 数据的变化不会直接触发 View 的更新:它始终要通过 Presenter , 由 Presenter 来更新 View 。这样在更新视图之前 Controller(Presenter) 还可以执行一些和展现相关的额外逻辑 。例如,同时更新另一些数据,它们和数据库中发生变化的数据有关;
  • 每个 View 对应一个 Presenter 。
这更接近我所见到的现在的请求/响应范式:数据流始终要经过 Controller/Presenter 。不过,Presenter 仍然不会主动更新视图,它始终需要执行一次新的请求才能让变化可见 。
MVP 中的 Presenter 又被称为 Supervisor Controller监督控制器 。
2.3 MVVM(Model-View-ViewModel)
六 软件架构MVC架构历史

文章插图
由于应用程序的复杂性还在增加,2005 年微软的 WPF 和 Silverlight 架构师 John Gossman 又提出了 MVVM 模式,目标是进一步将 UI 设计从代码中分离出来,并提供 View 到数据模型的数据绑定机制 。MVVM 背后的思想是:
  • ViewModel 和 View 一 一对应;
  • 将 View 中的逻辑转移到 ViewModel 来简化 View;
  • View 使用的数据和 ViewModel 中的数据一 一对应;
  • 将 ViewModel 中的数据绑定到 View 中的数据上,这样 ViewModel 中数据的变化会立即体现在 View 上 。
2.4 MVPVM(Model-View-Presenter-ViewModel)
六 软件架构MVC架构历史

文章插图
MVPVM中, View Model 是 Martin Fowler 在 2004 年提出的 Presentation Model, 。
  • Model
    一组包含业务逻辑和用例的类 。
  • View
    一个模板,模板引擎用它来生成 HTML;
  • ViewModel(又叫做 Presentation Model)
    从查询中接收(或者从 Model 实体中提取)原始数据,持有这些模板会用到的数据 。它还要封装复杂的展现逻辑,来简化Model 。这样我们才能将 View 和 Model 完全隔离开:
    • Model 中的变化(比如实体结构的变化)会上升并影响 ViewModel,但不会影响Model;
    • 复杂的展现逻辑被封装到了 ViewModel 之中,因此不会被泄露到领域(DDD领域设计的domain)之中;
    • Model的依赖变得很清晰,因为它们必须在 ViewModel 中设置 。
  • Presenter
    接收 HTTP 请求,触发命令或查询,使用查询返回的数据、ViewModel、模板和模板引擎生成 HTML 并将它返回给客户端 。所有 View 的交互都要经过 Presenter 。
三、总结【六 软件架构MVC架构历史】

推荐阅读