标签归档:flux

前端架构:Flux架构初探

最近查找React Transaction的相关资料的时候,无意中看到了Flux这个东西,简单看了一下,突然想到了我以前稍微想过的一个前端架构.

以前是这个想的:

(Controller) ->   (View)

所有关于操作视图的逻辑都单独抽出来,Controller负责处理所有非视图逻辑,这样做的一个好处就是可以将视图部分和逻辑部分分隔开,修改逻辑或者视图并不需要在一堆代码中寻找,只需要找到相应视图变化点,切入修改非常方便.

data=controller.requestData();//获取数据

data=controller.transData(data);

controller.bind(‘click’,view.getButton1(),function(){ controller.doBtn1Click();});//监听

view.renderAll(data);//更新全部视图

view.renderHead(data);//更新头部视图

但这样的一个缺陷就在于大部分关于DTO的逻辑会掺在Controller当中,整个业务逻辑十分不透明,

然后改成了这样:

(Data Model)  ->  (Controller) -> (View)

将数据模型单独抽离出来,Controller部分将更加地清晰

controller.init(); //初始化controller

controller.bind(‘click’,view.getButton1(),function(){ controller.doBtn1Click();});//监听

renderData=dataModel.getData(); //从数据模型获取数据

view.renderAll(renderData);// 完成视图

读了Flux之后,按照这种思想来了一套我所想的Flux

 

其实在前端领域,没有什么真正的所谓的MVC,Flux则从这种MVC的思想框当中跳出来,提出了有一个更适合前端架构的一个架构模型,我也用过类似React的一个前端框架,正如React本身所介绍的那样,React仅仅是一个View层解决方案,如果单使用React代码还是一团糟,其实这种理解是建立在一个范围上的,如果单看View层,React其实已经做到了视图分离,控制器自行去指派各种事件,视图与数据模型的同步也都做得不错,看起来已经像是一个比较小的MVC,但从前端整体看来,这种分离还是不够透彻,各个部分的逻辑还是只能写在render之前,双向数据绑定经常会出现数据不同步的情况(React本身也不支持双向数据绑定),所以最终React只能成为一个View层解决方案.

Flux则提供了一种新的思路,使得数据流向真正的成为了一个单向的过程,这样的一个最好的优点肯定是稳定性要好很多,数据不同步几乎不可能发生(没控制好也可能发生),下面稍微讲一下我理解的Flux架构(有些地方不太一样),所以一下称为这种前端架构.

这种前端架构主要是由Dispatcher,Store,View,Action四部分组成,实际上一切的开始都是Action触发的,所以顺序是Action->Dispatcher->Store->View,但Action的始终还是View,所以我把它放到了最后.

Dispatcher是事件分派器,起初数据仓库里面并没有数据,由事件分派器通过分析事件,将所需的数据列表或者事件发给Store,事件的来源是Action.在Flux中,数据请求是在Action中发送的,但我将这一步移到了Store中,目的是让Store的数据仓库除了具备数据仓库,又具备数据获取的功能.如果可能,前端的数据仓库与后端数据仓库也可以保持1:1的同步状态.

Store是数据仓库,数据仓库包含大部分的DTO逻辑,数据的相关操作是由事件分派器所传出的指令操作的.数据的推送是通过事件,但此时的事件分派器是被弱化的,与Dispatcher不同,是一种属于View的事件机制.

View是视图,所有视图的数据来源都是Store,按照规定,View在任何时刻都不应该主动访问Store去获取数据,而是通过触发Action再通过Dispatcher分配最终间接获取数据,Store也不应该提供对外接口供View访问,这样就可以保证数据的一致性.

为了让整个前端架构的View层更加详细,下面再引入React,扩充View.

State是Store数据与render数据的暂存区,由于React可以保障renderData与State之间的同步关系,所以我们只需要做到State与Store之间的同步关系就可以,这种解决方案就是通过上述的Flux去维持.而中间的React VitrualDOM能使View更加高效灵活.