MVC模型 解决问题以及不足
- 解决问题
为了解决业务逻辑和界面渲染逻混在一起
2. 不足
由于 Model 对外直接暴露了 set 和 on 方法，导致 View 层可以随意改变 Model 中的值，也可以随意监听 Model 中值的变化。这样的设定最终会导致一个庞大的 Model 中 某个字段变化后，可能触发无数个 change 事件。在这些 change 事件的回调中，可能还有新的 set方法调用，导致更多的 change 事件触发。
FLUX模型解决问题以及不足
- 解决问题
- 相对于完全只使用 React实现项目： 应用的状态数据只存在于 React组件之中， 每个组件都要维护驱动自己 渲染的状态数据，单个组件的状态还好维护，但是如果多个 组件之间的状态有关联，那就麻烦了。 比如子组件和父组件，父组件需要维护所有 子组件计数值的总和， 子组件和 父分别维护自己的 状态，如何同步 父 和 子 状态就成了问题， React 只提供了 props 方法让组件之间通信，组件之间关系稍微复杂一点，这种方式就显得非常笨拙。
- 相对于MVC数据模型: 解决MVC模型数据流混乱的形态，实行较为严格的 ‘单向数据流’的管理方式，MVC 最大的问题就是无法禁绝 View 和 Model 之 间的直接对话，对应于 MVC 中 View 就是 Flux 中的 View，对应于 MVC 中的 Model 的就 是 Flux 中的 Store，在 Flux 中， Store 只有 get方法，没有 set方法，根本可能直接去修改 其内部状态， View 只能通过 get方法获取 Store 的状态，无法直接去修改状态，如果 View 想要修改 Store状态的话，只有派发一个 action对象给 Dispatcher。
2. 不足
- Store之间存在明显依赖关系
在 Flux的体系中，如果两个 Store之间有逻辑依赖关系，就必须用上 Dispatcher的 waitFor 函数。 父组件对 action类型的 处理，依赖于子组件已经处理过了。 所以，必须要通过waitFor函数告诉Dispatcher, 先让 子组件处理这些 action对象，只有 子组件搞定之后 父组件才 继续。 - 难以进行服务器端渲染
如果要在服务器端渲染，输出不是一个 DOM 树，而是一个字符串，准确来说 就是一个全是 HTML 的字符串 。 在 Flux 的体系中，有 一 个全局的 Dispatcher，然后每一个 Store 都是一个全局唯 一 的对象，这对于浏览器端应用完全没有问题，但是如果放在服务器端，就会有大问题 。和一个浏览器网页只服务于一个用户不同，在服务器端要同时接受很多用户的请求， 如果每个 Store都是全局唯一的对象，那不同请求的状态肯定就乱套了 。 - Store 混杂了逻辑和状态
Store 封装了数据和处理数据的逻辑,当我们需要动态替换一个 Store 的逻辑时，只能把这个 Store 整体替换掉，那也就无法保持 Store 中存储的状态 ,例如: 在开发模式下，开发人员要不停地对代码进行修改，如果 Store在某个状态下引发了 bug，如果能在不毁掉状态的情况下替换 Store 的逻辑，那就最好了，开发人员就可以不 断地改进逻辑来验证这个状态下 bug 是否被修复了 。
Redux模型解决问题以及不足
1. 原则以及解决问题
- 单一数据源
在 Flux 中, 应用可以拥有多个 Store，往往根据功能把应用的状态 数据划分给若干个 Store 分别存储管理 。如果状态数据分散在多个 Store 中，容易造成数据冗余，这样数据一致性方面就会出 问题。 虽然利用 Dispatcher 的 waitFor方法可以保证多个 Store之间的更新顺序，但是这 又产生了不同 Store之间的显示依赖关系，这种依赖关系的存在增加了应用的复杂度，容 易带来新的问题 。 Redux 对这个问题的解决方法就是，整个应用只保持一个 Store，所有组件的数据源 就是这个 Store 上的状态 。 这个唯一 Store上的状态，是一个树形的对象，每个组件往往只是用树形对象上一部 分的数据 。
Redux 和 Flux 之间最大的区别就是对 store/reducer 的抽象，Flux 中 store 是各自为战的，每个 store 只对对应的 controller-view 负责，每次更新都只通知对应的 controller-view；而 Redux 中各子 reducer 都是由根reducer统一管理的，每个子reducer的变化都要经过根reducer的整合
- 状态是只读的
这一点和 Flux 的思想不谋而合，不同的是在 Flux 中，因为 store 没有 setter 而限制了我们直接修改应用状态的能力，而在 Redux 中，这样的限制被执行得更加彻底，因为我们压根没有 store。 在 Redux 中，我们并不会自己用代码来定义一个 store。取而代之的是，我们定义一个 reducer， 它的功能是根据当前触发的 action 对当前应用的状态(state)进行迭代，这里我们并没有直接修 改应用的状态，而是返回了一份全新的状态。 Redux 提供的 createStore 方法会根据 reducer 生成 store。最后，我们可以利用 store. dispatch 方法来达到修改状态的目的 。 - 状态修改均由纯函数完成
纯函数就是 Reducer, Redux 这个名 字 的前 三 个字母 Red 代表的就是 Reducer。 按照创作者DanAbramov的说法， Redux名字的含义是Reducer+Flux。 在 Redux 中，每个reducer 的函数 reducer(state , action), Flux 更新状态的函数只有一个参数 action，因为状态是由 Store 直接管理的，所以 处理函数中会看到代码直接更新 state 。
