前端框架，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并没有提升我们的开发效率）。但是由于业务系统并非只有视图逻辑，所以，当我们使用框架的时候，如果把所有业务流都在组件中完成，那么最后就是让业务很难维护。前端开发如果在谈技术选型时，只是讨论框架选择和工程化方式，那么可能考虑的东西还是太少了。我们应该适当的跳出现有的前端开发框架，去思考有关业务真正所关心的东西，从更高的层面去看问题。