阅读 1739

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

在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进来,完全没问题。

一些很好的学习对象

重要的是意识

要对前端工程化有一个全局的意识,知道自己写的代码位于架构分层的什么位置,并且有意识去汲取其他竞品、其他领域的经验,为自己所用。

期待前端能有一个自己的Spring框架。

关注下面的标签,发现更多相似文章
评论