Robust 第 15 期:跳出框架看前端分层结构

时下最火的前端框架,说白了实际上都是视图开发框架。前端开发除了遵循框架的范式外,实际上还有很大的空间。但是实际上前端开发不单单只包含视图层开发。我们关注的核心,实际上包含了界面、数据、业务、事件。本期robust就来聊一聊,前端分层结构,如何发挥MVC,梳理出前端开发的结构层次。

网易云音乐:点击播放

喜马拉雅:点击播放

求打赏🙇如果你觉得 Robust 这样一档技术类的谈话节目还不错,希望我继续做下去,不妨打赏支持。你可以扫描本文下方的二维码打赏,也可以加我微信后红包打赏。

内容大纲

前端框架,angular、vue等,据称是遵循MVVM,但在我看来不是这么回事。
前端编程(主要指基于数据的管理系统)我个人认为主要关注:
  • 界面
  • 数据
  • 业务
  • 事件(划重点)
前面三者,通常我们会对应到MVC,而事件,说白了,就是用户点击、拖拽等此类事件,不是指更抽象的编程事件系统。为什么事件不属于界面编程呢?因为事件的副作用不是影响界面,事件的副作用往往是影响数据,从而最终影响界面,而如何影响数据,往往是根据业务需求。正是因为现在所有系统中都将事件作为界面编程的一部分,导致很多前端界面代码中穿插了业务代码,最后根本不存在MVC之分,一个组件完成一切。
一个组件完成一切也不是不可行,只是不够好。MVC要解决的问题,不用MVC也不是不行,就是不够好。怎么样算好呢?本期就来聊一聊这个话题。
1. 状态驱动UI
  • 界面是状态的映射
  • 组件化
2. 领域模型
状态管理实质上是V层的编程,而非M层的。哪些是M层的东西呢?
  • 后端接口交互,Domain State 是一个伪命题
  • 数据强约定:前端只能用模型中规定的字段,至于后端返回什么数据,无关
问题在于,如何让状态拥有对接模型的能力?最简单的办法,就是将一个模型实例化之后作为一个状态,在组件中使用这个状态化的模型。
如果非要说Domain State,那么模型实际上可以分为 Domain Service(也就是和后端接口进行交互服务)和 Domain Model(也就是业务对象的抽象模型),而网上所讲的 Domain State 是将这两部分杂糅在一起后,作为状态交给状态管理器,作为整体状态的一部分,这部分和后端接口紧密耦合,但是实质上是一个复杂多态的状态,而非我们这里说的模型。
3. 事件流
重新审视组件中的交互响应。为什么我们要在组件的事件回调函数中写业务逻辑?
我们将业务逻辑的部分单独抽离出来。事件响应的代码,只负责将这个事件抛出去,至于具体的业务流程怎么走,并不在组件中去完成,对于组件而言,我就是接收状态(包含状态化模型实例),然后渲染。
rxjs天然具备这个优势,它是对事件触发逻辑的高度抽象,用在这里最好不过了。它不仅抽象出了事件触发逻辑,而且还提供了触发之后如何处理事件(本质上就是将事件响应转化为数据响应的过程)的方法。
4. 业务流
如果没有复杂的业务场景,直接在组件的事件回调函数中写业务流程实际上也是可行的。有的时候,一个业务分散到好多个组件中,虽然感觉杂乱,但是认真花点时间阅读,还是能理清楚业务过程。
但是,如果遇到一个事件,触发了多个业务流转的时候,就比较麻烦了。比如说,一个订单相关的按钮,点击之后,不仅要更新订单的状态,还要更新商品的库存信息,还要更新店铺的信誉度,而店铺的信誉度又要影响它的排名等等。也就是说,一个click事件,可能引发多条业务流转,甚至牵一发而动全身的一系列长串业务流程。这种情况下,就不是一个回调函数能解决的。
我们要重新抽象出业务流转模型。每一个业务流转独立撰写,在一个模型中可能涉及其他业务流转模型,要引入进来。而流转过程则可以利用rxjs的操作符进行组合,这样可以为后续重新组合打好基础。
在业务流转中,可能会调用领域模型,不断的操作模型状态,从而触发状态变化,进而调整界面。
5. 融合
所以,整个流程就是从数据开始,拿到后端数据后,实例出对应的模型实例,将这个实例作为状态的一部分交给视图层去渲染。视图层完成渲染,监听用户的交互事件,并将交互事件通过事件流系统提交给业务流转系统,业务流转系统根据业务逻辑,更新模型,同时完成和服务端数据的同步。模型变更之后,作为状态的一部分的模型实例,触发状态通知,进一步触发界面更新。
其中,Domain Service 到底是算状态的部分,还是算模型的部分?这不是很好回答。但是你可以在实践中去尝试,如果算状态的一部分,那么会导致模型触发状态更新之后,状态去请求接口回来,又要反过来更新模型,形成死循环。所以,将它放在模型部分可能更好,把 Service 层作为和模型层一起工作的同等地位的服务,模型更新时,触发 Service 和后台接口的交互。由于ajax是异步的,所以等到交互完成之后,可能需要再更新模型一次,这样,一个来自视图层的事件,可能触发多条业务流,每条业务流可能触发多个接口交互,这样的逻辑就更顺利了。而且由于view层是响应式的,异步任务中,多次更新是前端实践的常见操作,因此,只要经过一系列状态变化之后得到正确的视图,就可以认为这套逻辑没有问题。
总结一下,前端分层结构包括:
  • 视图层(View)- 状态管理(State Management)
  • 模型层(Domain Model)- 接口服务(Domain Service)
  • 事件流(Behavior)
  • 业务流(Action)
总结就是:MVBA
而我们大书特书的 react,实际上只是 view 层的东西,redux 则是状态管理范畴,也算是 view 层的东西。模型层、事件流、业务流,这些东西在前端生态中,似乎不是什么要紧的事,因为没有它们,照样能完成需求。
但是,作为讨论,我觉得如果一个业务系统想要能够长期迭代中不迷失方向,这些都是需要的。
我们看下哪些工具可以帮助我们完成上述这个架构:
  • 视图层:react,状态管理:redux
  • 模型层:tyshemo,接口服务:databaxe
  • 事件流:rxjs
  • 业务流:rxjs
6. 拆分
如果我们的一套系统是按照这样设计,那么拆分就会变得更容易一些。举个例子,我们有一套系统,有web PC版、基于React Native实现的手机客户端。
如果基于我们传统的开发方式,你发现,同样一个业务,比如下订单这个业务,两个平台,感觉全都要重新开发。而如果我们使用了上述的分层开发方式,那么,实际上主要是重写视图层,也就是将 react-dom 替换为 react-native。而其他层几乎都可以复用,比如数据请求,比如业务流转,比如领域模型,全都可以复用,在实际编程中,可能还是需要做一些适配,但是不用担心两个平台核心的业务逻辑会不一致。
甚至,如果前端需要用 angular 替代 react,那么也是替换视图层的东西。虽然代价会比较大,但是也不是不可能,因为大部分主要是去更新视图交互的代码逻辑,而且要考虑react和angular的数据流逻辑问题。但是,其他方面仍然可用,没有任何问题。
7. 总结
市面上的大部分框架是基于技术层面,通过统一开发范式,解决我们在视图层的开发效率问题(实际上react并没有提升我们的开发效率)。但是由于业务系统并非只有视图逻辑,所以,当我们使用框架的时候,如果把所有业务流都在组件中完成,那么最后就是让业务很难维护。前端开发如果在谈技术选型时,只是讨论框架选择和工程化方式,那么可能考虑的东西还是太少了。我们应该适当的跳出现有的前端开发框架,去思考有关业务真正所关心的东西,从更高的层面去看问题。

2020-05-31 189 ,

为价值买单

本文价值1.89RMB