Flux 架构介绍

MVC 框架缺陷

MVC的全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，是一种软件设计典范。

• M：即是 Model 模型是管理数据，很多业务逻辑都在模型中完成。在MVC的三个部件中，模型拥有最多的处理任务。
• V：就是View视图是指用户看到并与之交互的界面
• C：是Controller控制器是指控制器接受用户的输入并调用模型和视图去完成用户的需求，控制器本身不输出任何东西和做任何处理。他只是接收请求并决定调用哪个模型构建去处理请求，然后在确定用哪个视图来显示返回的数据。

MVC 缺陷：

• MVC 框架的数据流很理想，请求先到Controller，由Controller调用Model中的数据交给View进行渲染
• 但是在实际项目中，又是允许Model和View直接通信的。然后就出现了这样的结果
• 导致混杂的数据流和不可预测的结果

Flux 介绍

在2013年，Facebook 让 React 亮相时，对于当时世面上的 MVC 框架并不满意，于是就有了Flux。并推出了 Flux ，但 Flux 并不是一个 MVC 框架，它是一种架构思想。

React： 实际初衷是用来替代 jQuery
Flux ：可以用来替代 Backbone.js ，Ember.js 等一系列 MVC 架构的前端JS框架。

• 创造目的：专门解决软件的结构问题，比如纠正MVC框架的无法禁绝view与model通信的缺点

• 如下图所示：数据总是"单向流动"，任何相邻的部分都不会发生数据的"双向流动"。这保证了流程的清晰。

• View：视图层
• Action（动作）：视图层发出的消息
• Dispatcher（派发器）：用来接收Action、执行回调函数
• Store（数据层）：用来存放应用的状态，一旦发生变动，就提醒Views要更新页面

---

Flux 的优点

• 单向数据流：

1. 用户访问 View 层，产生操作（Action ）
2. View 发出用户的 Action 给 Dispatcher
3. Dispatcher 收到后要求 Store 进行更新
4. Store 更新后会触发一个 change 事件
5. View 监听到 change 事件后，更新页面

---

Flux 的缺点

• Store之间依赖关系

1. 如果两个 Store 之间有逻辑依赖关系，就必须用上 Dispatcher的 waitFor 函数。
2. SummaryStore 对 action 类型的处理，依赖于 CounterStore 已经处理过了。
3. SummaryStore 靠register 函数的返回值 dispatchToken 标识 CounterStore 
4. 而dispatchToken的产生，是CounterStore控制的

• 难以进行服务器端渲染

1. 在Flux的体系中，有一个全局的 Dispatcher，然后每一个 Store 都是一个全局唯一的对象
2. 在服务器端要同时接受很多用户的请求，如果每个Store 都是全局唯一的对象，那不同请求的状态肯定就乱套了。

• Store混杂了逻辑和状态

1. Store封装了数据和处理数据的逻辑
2. 当我们需要动态替换一个Store的逻辑时
3. 只能把这个Store整体替换掉
4. 那也就无法保持Store中存储的状态

---

Flux 的流程：

1. 组件获取到 store 中保存的数据挂载在自己的状态上
2. 用户产生了操作，调用actions的方法
3. action 接收到了用户的操作，进行了一系列的逻辑代码、异步操作
4. 然后action 会创建出对应的 action ，action 带有标识性的属性
5. action 调用 dispatcher 的 dispatch 方法将action 传递给 dispatcher
6. dispatcher 接收到 action 并根据标识信息判断之后，调用store的更改数据的方法
7. store 的方法被调用后，更改状态，并触发自己的某一个事件
8. store 更改状态后事件被触发，该事件的处理程序会通知 view 去获取最新的数据