理解 MVC 的关键：M 与 C

MVC 关系图

对于 MVC 的理解，我发现争论最大的是：如何理解 M 层与 C 层，即模型层与控制层间的关系以及各自承担的职责。至于视图层，在前端的开发中就显得比较的「薄」。它主要包含了 HTML 和 CSS 文件，负责搭建视图静态框架。虽然在 MVVM 的框架中，视图层的职责略有不同，但这部分差异我们后面再谈。

写这篇文章的契机是由于我在实际的开发中发现：随着项目的不断壮大，控制层变的越来越臃肿，开发和维护的成本变的很高。这使得我逐渐开始质疑自己对 MVC 的理解。

起初，我对 MVC 中 M 的理解是：Model = 数据模型。

我当时认为 Model 指的就是「数据模型」或是「数据层」，该层负责封装数据相关的逻辑，然后为控制层提供所需的接口。比如某个视图的控制器需要获取数据 A ，而数据 A 可能来源于本地缓存、服务器X、服务器Y等多个数据源。这部分逻辑的整合就会被封装到某一个数据模型中，然后向外提供一个接口，供控制层调用。

如果是在一个数据复杂度较高的项目中，我上述对 Model 的理解虽然依然不能够缓解控制层不断膨胀的趋势，但或许还能够感受到些许好处。可是在我负责的项目中，虽然业务逻辑非常的多，但由于大部分的后台接口都是定制接口，数据源也比较单一，所以数据的复杂度并不高，Model 层只是封装了一堆简单的接口调用逻辑。Model 层过于的「薄」导致几乎所有的业务逻辑都扔到了控制层中。

于是乎，我隐约感觉到：Model ≠ 数据模型。

经过深入的思考，我现在对 MVC 中 M 与 C 的理解分别是：

• Model 指的是对同一类业务行为进行抽象而得到的业务模型，它与视图层和控制层并没有任何关系，它应该是独立存在的。

• Controller 负责事件的处理和各个业务模型间的调度，最后将视图层需要的数据，也就是状态(state)，反应到视图中。

MVC 分层结构

举个简单的例子：假如我们正在开发用户登入方面的功能，在架构的时候我们往往会设计一个用户模型，里面封装了用户登入和登出的行为，其核心逻辑分别是调用后台的登入接口获取 token 和将本地的 token 删除。这部分的封装很好理解，即使将 Model 理解为数据模型，我们也会这么做。

除了登入和登出，我们还需要对用户输入的账号和密码的有效性进行提前校验，比如：账号必须是一个手机号，密码至少是六位数。这部分需求分别对应两个业务行为：用户账户有效性的校验和用户密码有效性的校验。显而易见，如果我们把 Model 看成是一个数据模型(即里面只能封装数据相关的行为)，那么上述两个行为就只能写在页面对应的控制器中，而不是抽象到用户模型中。

我们使用某一开发模式的初衷是为了减少开发的复杂度，使代码更容易被理解和管理。一个高质量的项目，即便是新来的同事，也能够很容易的理解项目中代码的逻辑并快速的投入到开发工作当中。

可以想象，当我们在翻阅用户模型的代码时，居然找不到用户账号和密码校验相关的代码块，而是需要在登入页面的控制器中才能找到，这种不适的感觉，我相信你能够感受的到。如果感受不到，我举个现实生活中的例子你就能有所体会了。

假设你去摄影店里拍证件照，但是他们最终给你的是一张未经剪裁的大照片，你叫他们给你剪裁成六张单独的照片，但是店家却说：我们不提供这种服务。。。虽然，我们家里也有剪刀，可以在家自己剪，但是这事儿不应该是店家的「本职工作」吗？

Q&A

1. 如果是把所有的业务逻辑都放在 M 层，那么 M 层会不会也变得非常臃肿？

需要注意的一点是，一个页面一般只会有一个控制器，如果这个页面的业务逻辑越来越多，要是把这些业务逻辑都放在控制器中，控制器显然会变的越来越臃肿。但是把业务逻辑都抽象到 M 层就不一样了，因为我们是将所有的业务逻辑分别抽象到多个业务模型中，也就是说 M 层中包含了多个业务模型。随着项目体量的增加，虽然部分业务模型的代码量也会增加，但由于模型本身已经是高度的抽象了，所以并不会过多的增加代码复杂度，其实更多只是增加了业务模型的数量而已，M 层只会越来越饱满，而不会显得臃肿。

2. 如何理解 MVC 与 MVVM 的关系？

1. MVVM 是在 MVC 基础上的优化，我对它的理解是：由于 MVVM 框架提供了数据双向绑定的能力，使得控制层不用操心如何将数据反应到视图中，而只需要维护那些绑定在视图上的数据既可以，从而进一步减少了控制层的复杂度。

2. MVVM 与 MVC 中的 M 的概念是一致的，指的都是业务模型。

3. 如果某一业务逻辑与视图的耦合度很高，是否还需要抽象到对应的业务模型中？

在实际的开发中，我们会发现许多的业务与视图的耦合度很高，这时我们总是会纠结是否将这部分耦合度很高的业务逻辑抽象到具体的业务模型中，因为这部分逻辑很难被其他地方复用。我的看法是：

抽象业务模型的初衷不是为了复用，而是为了方便管理。

比如在 A 页面和 B 页面都有一个 a 行为，但是在两个页面中，a 行为的实现方式完全不一样，且对页面都有着极高的耦合度。如果该行为对应的业务模型是 M ，我的做法是：将两个行为都抽象到 M 中，其对外的接口名分别是：aForPageA 和 aForPageB ，而不是因为其极高的耦合度就代码卸载页面对应的控制器中。这样做得好处是我们将理应属于 M 模型的行为都抽象到了该模型中，使得代码非常的容易被理解和管理。而对于那些耦合度较高的行为我们可以为其定制更加语义化的接口名，以方便其他同事的理解与后续的重构。但需要注意，假如项目的业务逻辑并不复杂，或者上述的 M 模型并不存在时，我们没有必要为这些高耦合的业务行为抽象出一个业务模型 M ，这样会产生不要的复杂度。在这种情况下，将那些业务行为写死在控制器中或许是更好的选择。

总结

1. MVC 中的 M 指的是业务模型而非数据模型。
2. 理想情况下，所有的业务逻辑都应该抽象 Model 层。
3. 理想情况下，控制层只是负责响应视图的事件和各个业务模型间的调度。
4. 具体情况具体分析，若是严格的遵循2、3两点也有可能增加项目不必要的复杂度，事事无绝对。一切都以降低项目复杂度为最终目的。