在MVVM分层之下
MVVM把一个系统拆分成视图层、视图数据层、数据访问层：
但我们要搞清楚一点，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进来，完全没问题。
一些很好的学习对象
重要的是意识
要对前端工程化有一个全局的意识，知道自己写的代码位于架构分层的什么位置，并且有意识去汲取其他竞品、其他领域的经验，为自己所用。
期待前端能有一个自己的Spring框架。