Flux Architecture如何比MVC更好

时间:2017-08-18 20:47:50

标签: javascript redux ngrx

我试着了解焊剂结构解决的真正问题是什么。

第一个主要问题

  • 存储作为状态管理。 redux(flux architecture implementation)动作的示例 - > store(reducer) - >视图。这是一种管理状态的简便方法。

但是在很多博客文章中他们都谈到了MVC /双向数据绑定。 我认为这是错误的,因为我没有看到flux架构如何关注双向数据绑定。 例如:

angularJs登录应用程序:

<div ng-controller="loginCtrl">
  username<input ng-model="username">
  password<input ng-model="password">
  <button ng-click="submit()">Send</button>
</div>

脚本:

angular.module('app',[]).controller('loginCtrl', function($scioe) {
  $scope.submit = function() {
    globalStore.dispatch({
      action: 'LOGIN', 
      payload: {
        username: $scope.username,
        password: $scope.password
      }
    })
  }
})

当然我不是在实际应用中这样做,但在这个例子中我可以使用双向数据绑定和存储。 在这种情况下FLUX VS MVC,解释是一个更改可以循环回来并在代码库中产生级联效果(使调试和理解变得非常复杂)。

FLUX VS MVC在这种情况下,他们说通量是良好的通量实施

所以我尝试在flux official site上阅读有关通量架构的内容,它们共享一个youtube视频并解释MVC变得复杂,并且可以进行循环播放。

我的问题:

  1. 助焊器架构解决了哪些问题?
  2. MVC或/和双向绑定问题的真实示例是什么。

3 个答案:

答案 0 :(得分:1)

我认为你必须在MVC与CBA(基于组件的架构)方面考虑更多,而不是Redux与MVC。

Redux可帮助您在组件之间同步状态,并在获得共享状态的复杂组件树时真正发光。

我想向您介绍这个优秀的演示文稿,它可以帮助您了解在基于组件的体系结构中使用Redux的好处。

在Angular 2中管理国家 - 圣路易斯角度午餐 - Kyle Cordes https://youtu.be/eBLTz8QRg4Q

答案 1 :(得分:0)

Facebook创建了Flux模式,以巩固许多React组件之间的状态管理。使用React,每个组件都能够维护它自己的状态。因此,我们需要小心如何为组件布置架构。通常来说,我们试图将开发视为一个大型组件,其中包含许多较小的组件......其中大部分状态管理由最外层组件维护。这适用于很多东西,但不是一切。

因此,发明Flux是为了补充React的单向数据流,以帮助在React组件之间创建更容易推理状态系统的理由。 Redux是一个类似的Flux实现,但更容易推理,因为Redux只有一个由所有组件共享的状态存储。

为了总结Flux和Redux试图解决的整个问题,我们必须考虑一个隔离组件的替代方案,以便能够与另一个隔离组件进行有效通信。 React有一个父子组件的单向流,但是当我们必须在那之外进行通信时会发生什么?这就是在组件外部有一个状态存储的地方很有意义。相反的是,在组件之间设置手动事件和事件监听器会非常快速地混乱。

答案 2 :(得分:0)

Facebook explains认为MVC迅速变得复杂**,并且很难招募新开发人员。

“ Flux和MVC之间的最大区别在于,您避免了级联更新” -video source at relevant time

所以他们改用Flux,风格上比OOP多FP。

但是Flux实际上只是在客户端正确实现的MVC(考虑到用户操作也必须通过Controller进行,而不仅仅是服务器交互)。

See the diagram here

商店=型号

调度程序=控制器

查看=查看

视图仅与Dispatcher / Controller对话,而不是直接与Store / Model对话(这与他们在错误的MVC实现中所拥有的东西相反;后者基于可观察性as heard here

与原始MVC的主要区别在于分派器确保:

“在您的商店层完全完成之前,视图或其他任何内容都无法通过系统执行操作。” -video source at relevant time

**-我只能猜测是由于“上帝对象”或“胖模型”,以及由于(糟糕的)OOP而增加的耦合。