浅谈Flux与MVC

一、Flux概述

Flux是Facebook用来构建用户端的 Web前端应用程序的体系架构，与其它形式化的框架相比，它更像是一个架构思想，用于管理和控制应用中数据的流向。这里应用中的数据指包括但不限于来自服务端的数据页面中view的一些状态(如一个面板是展开还是关闭)，临时存储在本地需要持久化到服务端的数据等。

好了，说了这么多好像还是一脸懵逼，不慌，接下来看看展开式。
 
 

二、MVC

在讲述 Flux之前，我们看看之前传统的MVC架构以及在web前端中的一些问题继而思考Flux带来的改变。 MVC(Model-View-Controller)最先兴起于后端，通过对应用程序复杂度的简化使程序更加直观和便于维护。后端程序MVC中View可以看为数据的呈现，Model为数据的模型，Controller作为程序的流程控制。

现在假设有这样的场景，用户想查看自己的profile页面，可能会有这样的流程：在页面上点击profile按钮，接下来就是一个HTTP请求(/profile?username=jiavan) => Controller接收到这一请求并获得请求的内容username=jiavan然后告知Model需要jiavan的数据 => Model返回了jiavan的数据 => Controller得到数据返回新的视图，看下流程：


 
现在前端中又有这样的场景：切换Menu中的Item，当前选中的Item颜色不同于其它颜色并且底部显示对应Item的内容。

一般情况下我们会定义一个css class来作为当前选中Item的样式。当用户点击Item_A为被点击的元素新增高亮的class，其它兄弟元素移除该样式，这里的事件响应函数就是Controller，我们会在这里处理样式修改逻辑，以及更新Model的数据，然后新的数据及样式重新渲染界面。

这种VC<->M的形式在关系比较简单的情况下是比较清晰容易控制的，但是复杂的页面上这样的模式可能会变得非常混乱：


 
之所以变得混乱了，因为很多view都具备修改多个model的能力，这里的单个修改行为可以称之为一个Action，一个Action的产生可能是用户行为，或者一个Ajax请求需要渲染新界面。对比上面后端传统MVC模式可以发现：

• 后端中Action作为一个URL请求，前端中可能是一个事件；
• 后端中Action处理被集中在Controller中，而前端中是分散的。

那么是不是可以把前端中修改状态即state的行为(事件回调/Ajax)全部抽象成一种Action描述，然后交付到一处即Reducers来进行原子化处理，然后Reducer修改整个应用中唯一的一棵state tree即Store，最后通过state->view的机制来重新渲染?

三、Flux数据流框架

上面提到的几个概念已经对Flux有了初步的了解，下面进入正题。相信有了解Flux的都应该看过下面这张著名的数据流图：

 
 

• Action可以看成是修改Store的行为抽象；
• Dispatcher管理着应用的数据流，可以看为Action到Store的分发器；
• Store管理着整个应用的状态和逻辑，类似MVC中的Model。

所以Flux可以被看作传统MVC的改进而非颠覆。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31494694/viewspace-2147768/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31494694/viewspace-2147768/