1. 首页
  2. IT资讯

Mvc 与 Flux 与 Redux的一些思考

MVC模型 解决问题以及不足

  1. 解决问题

为了解决业务逻辑和界面渲染逻混在一起

Mvc 与 Flux 与 Redux的一些思考
MVC流程图

2. 不足

由于 Model 对外直接暴露了 set 和 on 方法,导致 View 层可以随意改变 Model 中的值,也可以随意监听 Model 中值的变化。这样的设定最终会导致一个庞大的 Model 中 某个字段变化后,可能触发无数个 change 事件。在这些 change 事件的回调中,可能还有新的 set方法调用,导致更多的 change 事件触发。

Mvc 与 Flux 与 Redux的一些思考
MVC 的问题

FLUX模型解决问题以及不足

  1. 解决问题
  • 相对于完全只使用 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。
Mvc 与 Flux 与 Redux的一些思考
Flux模型

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的整合
Mvc 与 Flux 与 Redux的一些思考
Flux 中的 store 流程图
Mvc 与 Flux 与 Redux的一些思考
Redux 中的 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 。

原文始发于:Mvc 与 Flux 与 Redux的一些思考

主题测试文章,只做测试使用。发布者:酒颂,转转请注明出处:http://www.cxybcw.com/25761.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code