自己做app的网站,平台推广营销,网站建设要会哪些方面,wordpress 纯代码 雪花MVC模型 解决问题以及不足解决问题为了解决业务逻辑和界面渲染逻混在一起 MVC流程图2. 不足由于 Model 对外直接暴露了 set 和 on 方法#xff0c;导致 View 层可以随意改变 Model 中的值#xff0c;也可以随意监听 Model 中值的变化。这样的设定最终会导致一个庞大的 Model …MVC模型 解决问题以及不足解决问题 为了解决业务逻辑和界面渲染逻混在一起 MVC流程图2. 不足由于 Model 对外直接暴露了 set 和 on 方法导致 View 层可以随意改变 Model 中的值也可以随意监听 Model 中值的变化。这样的设定最终会导致一个庞大的 Model 中 某个字段变化后可能触发无数个 change 事件。在这些 change 事件的回调中可能还有新的 set方法调用导致更多的 change 事件触发。 MVC 的问题 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。 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的整合Flux 中的 store 流程图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名字的含义是ReducerFlux。 在 Redux 中每个reducer 的函数 reducer(state , action), Flux 更新状态的函数只有一个参数 action因为状态是由 Store 直接管理的所以 处理函数中会看到代码直接更新 state 。
