MVC 模式中的 3 种角色

在 MVC 模式中,主要涉及 3 种角色——Model、View 和 Controller,下面简要介绍一下它们。

 Model

Model 负责保存应用数据,和后端交互同步应用数据,或校验数据。

Model 不涉及用户界面,也不涉及表示层,而是代表应用程序可能需要的独特形式的数据。 当 Model 改变时,它会通知它的观察者(如视图)作出相应的反应。

总的来说,Model 主要与业务数据有关,与应用内交互状态无关。

 View

View 是 Model 的可视化表示,表示当前状态的视图。前端 View 负责构建和维护 DOM 元素。View 对应用程序中的 Model 和 Controller 的了解是有限的,更新 Model 的实际任务都是在Controller 上

用户可以与 View 交互,包括读取和编辑 Model,在 Model 中获取或设置属性值

一个 View 通常对应一个 Model,并在 Model 更改时进行通知,使 View 本身能够进行相应的

更新。但在实际应用开发中,还会面临多个 View 对应多个 Model 的情况。

在前端 MVC 体系中,View 对应的是 JavaScript 模板语言,它用于将 View 定义为包含模板 变量的标记,使用变量语法,接受 JSON 数据格式的数据。而 React 本身具备模板这一特性,这 一点在第 1 章中已经提过。

 Controller 负责连接 View 和 Model,Model 的任何改变会应用到 View 中,View 的操作会通过 Controller

应用到 Model 中。

在前端 MVC 框架中,Controller 的设计和传统 MVC 中的概念还是不太一样。如 Backbone, 包含 Model 和 View,但它实际上并没有真正的 Controller。其 View 和路由的行为与 Controller 有 些类似,但它们实际上都不是 Controller.

总的来说,Controller 管理了应用程序中 Model 和 View 之间的逻辑和协调

2. MVVM 的演变

MVVM 出现于 2005 年,最大变化在于 VM(ViewModel)代替了 C(Controller)。其关键“改 进”是数据绑定(DataBinding),也就是说,View 的数据状态发生变化可以直接影响 VM,反之 亦然。这也可以说是 AngularJS 的核心特色之一。

3. MVC 的问题

MVC 乍一看似乎没有特别值得诟病的地方,但是它存在一个致命的缺点,这个缺点在你 的项目越来越大、逻辑越来越复杂的时候就非常明显,那就是混乱的数据流动方式,

以 Backbone 为例,由于 Model 对外直接暴露了 set 和 on 方法,导致 View 层可以随意改变Model 中的值,也可以随意监听 Model 中值的变化。这样的设定最终会导致一个庞大的 Model 中 某个字段变化后,可能触发无数个 change 事件。在这些 change 事件的回调中,可能还有新的 set 方法调用,导致更多的 change 事件触发。

更糟糕的是,一个 Model 还能改变另一个 Model 的值,整个数据流动的方式变得更加混乱, 不可捉摸。可以预见,在这种复杂的监听和触发的关系中,梳理数据的流动方式,甚至调试业务 逻辑都成了一种奢望。

对于增、删、改来说,MVC 都需要编写 View 渲染处理函数。当业务逻辑变复杂后,可能会 有很多 Model 需要做增、删、改。与之对应的是,我们需要精心构建 View 渲染处理函数。尽管 局部更新模式是高性能的关键所在,但这点会导致更新逻辑复杂,并需要编写大量的局部渲染函 数,也会导致问题定位困难。页面的当前状态是由数据和局部更新函数来确定的。

在实际应用中,前端 MVC 模式的实现各有各的理解。在 Google Images 中搜索“前端 MVC”, 从得到的结果可以看到,几乎每个人对 Model、View 和 Controller 都有自己的理解,而它们之间 的连线更是千奇百怪

1

4. 解决方案

如果渲染函数只有一个,统一放在 Controller 中,每次更新重渲染页面,这样的话,任何数 据的更新都只用调用重渲染就行,并且数据和当前页面的状态是唯一确定的。这样又要保证数据 的流动清晰,不能出现交叉分路的情况。

然而重渲染会带来严重的性能与用户体验问题。重渲染和局部渲染各有好坏,对 MVC 来说 这是一个两难的选择,无法做到鱼和熊掌兼得