MVVM分层下的前端工程化开发

MVVM把一个系统拆分成视图层、视图数据层、数据访问层：

对于基于MVVM架构的库，View层就是DOM，ViewModel层就是组件，Model层就是state或props。此外，如果我们使用状态管理库，那么Model层就是store。

但我们要搞清楚一点，MVVM是MVVM库设计时所遵循的原则，而不是我们写代码时应该遵循的。我们只是在MVVM分层下，分别在Model、VM、View这三个部分写自己的业务代码。

因此，我们还需要找出一系列范式，在基于MVVM的大流程下，指导我们写出分层合理、可拓展的业务代码。

库与框架

库 + 范式 = 框架

遗憾的是，由于缺少官方给出的一系列范式，我们常用的React和Vue并不是框架。

幸运的是，我们还有Angular。

其实到这里，我们可以直接去翻阅Angular的文档，然后取其精华，应用到自己的React或Vue的项目之中

Angular架构概览： www.angular.cn/guide/archi…

自己发掘范式

从后端说起

我们要知道前端工程化的历史一共不过几年，其中的积累必然没有后端多，所以有一定的后端知识，对前端工程化开发是很有裨益的。

如果我们去看一个优秀的后端项目，我们的第一印象肯定是：哇，分了这么多的层，而且每一层都做到了解耦，看起来很高大上的感觉！

这说明，后端的确有至少一个非常成熟的框架来指导后端业务代码的书写。

后端是如何解耦业务代码逻辑的

在第一小节说过，我们的业务代码是位于在MVVM分层之下的，大量的业务逻辑代码会出现在VM这一层。对于后端来说，大量的业务代码也同样会出现在MVC的Controller这一层。

在这里，无论前端和后端都会面临同样的问题：如何解耦这些复杂的业务逻辑。

后端工程师是幸运的，Spring这个元老级的框架已经为他们铺设好了大量的基础设施，像是依赖注入、面向切片编程以及大量优质注解和上层封装接口。同时，社区也总结出了如下图的业务逻辑分层：

有了基础设施，再结合社区的经验，后端工程师能很容易的拆解业务逻辑，并复杂的业务逻辑从Controller拆分到Service层，Service再通过DAO层进行数据库读写。

但作为前端工程师，如果我遇到这种情况，就会比较迷茫。

类比学习

其实上述的分层是能为前端所用的，我们只需要根据前端的实际情况做一些适应性修改即可。

先思考一个问题： 为什么要有Service层

在MVC中的Controller层，服务器需要接收来自Client的请求，经过一些处理，最后返回一个合理的响应。在这个过程中，不可避免地需要与数据库进行交互，如果把请求的读取、数据库的读写、响应的拼装都放在Controller里的话，代码必然会变得难以维护，所以才有了Service层，这就是后端需要解决的痛点。

再思考一个问题： 前端有没有上述痛点

后端的过程是这样的：接受请求、数据库读写、返回响应。

前端的过程是这样的：组织参数、发起请求、处理响应。

如果我们把这三个过程都写在VM里（通常是我们的组件），代码肯定会变的难以维护，单元测试更是想都别想。

最后思考一个问题： 怎么让Service层为我所用

Service的正确使用 姿势 应该是跟Spring这样的有控制反转功能的框架结合，通过依赖注入的形式得到Service实例，然后直接使用这个实例。

Angular官方文档已经给出基于依赖注入的Service使用方式了，直接去看即可： www.angular.cn/guide/archi…

然而作为React和Vue的用户，该怎么用呢？

条条大路通罗马，怎么用都可以。举个例子，我就单独新建一个dashboardSrv.js文件，然后把所有涉及到网络请求的复杂业务逻辑都放进去，然后在组件里import进来，完全没问题。