MVC,Flux和Redux的真正区别

       在Web应用开发过程中，我们创建了很多解决方案来满足客户需求，同时也解决了很多企业和用户的问题。为了实现这一点，使用了不同的架构设计模式和技术方案。多年来，应用程序的设计是围绕着MVC(Model-View-Controller)设计模式。与此同时，涌现了一系列更先进的框架，如Flux和Redux，同样能帮助你处理复杂的应用程序。我们意识到，由于缺乏有效的设计模式，应用程序的复杂性会成倍增加。在这里，我们比较了 MVC、Flux 和 Redux，以帮助您创建有效、合理和可扩展的应用程序架构。

MVC, Flux和Redux的比较

1. 架构

MVC	Flux	Redux
MVC - 模型 视图 控制器 适用于开发UI的架构设计模式	为构建Web客户端的应用架构设计	适用于创建UI的开源JavaScript库 通常适用于React和Angular开发

MVC 架构

    MVC以其三层架构模式而闻名，它将应用程序分为三个组件(components):

• Model: 维护应用程序的数据和行为
• View: 在UI中显示数据模型
• Controller: 作为视图和模型组件之间的接口

每当控制器收到用户的请求时，它就会使用对应的模型和视图生成应答响应给用户。

Flux 架构 

       在研究了一些关于MVC架构的不稳定性和复杂性突出问题之后，Facebook 开发团队对系统进行了一些重要的更改，并发布了Flux作为MVC架构的替代方案。Flux架构包含以下组件：

• Store/Stores: 作为应用程序State和逻辑的容器
• Action: 传输数据到Dispatcher
• View: 等同于MVC架构中的View, 但是以React组件的概念存在。
• Dispatcher: 协同Actions更新至Stores

        在 Flux架构中，当用户发起点击事件时，View创建Actions, Action可以创建新的数据并发送至Dispatcher. 然后Dispatcher发起Action结果至对应的Store, Sotre 基于这个结果更新State并发送一个更新至View。

Redux 架构

       然而，Dan Abramov觉得这种架构可以更简单，因此，Dan Abramov 和 Andrew Clark 在 2015 年开发了 Redux。Redux是一个库，它以一种完全不同的方式实现了Flux的思想，Redux架构介绍了一些新的组件：

• Reducer: 是一个只包含逻辑的纯函数，决定了你的数据如何变化。
• Store(全局一个): 持有一个State对象，表示整个应用程序的State。

       在Redux架构中，应用程序的事件表示为Action, 它被派发至纯函数Reducer，然后reducer根据它接收到的Action类型用新数据更新中心Store。Store创建新的State并发送一个更新至View, 此时View会被重新绘制以响应更新。

2. 数据流方向

MVC	Flux	Redux
遵循双向数据流	遵循单向数据流	遵循单向数据流

      类MVC设计模式是强制双向数据流的，这个和Flux,Redux维护的单向数据流不同。在MVC中，应用程序没有单个方向的数据流。系统的不同部分拥有更改状态的权限，并且状态在整个应用程序中都是分散的。例如，考虑一个大型应用程序，需要收集的数据模型包括用户，鉴权，账号等信息。这些信息被绑定在模块内部的Controller和View中，那么将难以定位State的切确位置，因为分布整个应用中。

       Flux和Redux为了确保数据流向的单一性，不提倡使用双向数据流。单向数据流的优势在于能够更好的控制它，因为在应用中数据流向是单一的。

3. 单个还是多个Stores

MVC	Flux	Redux
没有Store概念	包含多个Store	包含单个Store

       在所有应用中，Flux都使用'Stores'缓存数据与状态的联系信息，而MVC则采用单个Model对象缓存。 MVC中没有Store的概念，Store更像是MVC中的Model, 但是Model在多个对象中处理State,而不仅由单个数据库记录表示。Flux和Redux的主要区别是，Flux在每个应用中存在多个Store, 而Redux仅有一个。Redux在整个应用中不会采用多个Stores存储State信息，而是把所有的State信息存在一个Store中。

       Redux为什么采用一个Store呢？ 想象一下你要处理多个Stores, 如果在某个Store中忘记处理一个事件，这会导致应用程序管理问题。另外，在模块外部很难获取State内部属性，还有更新也是Flux中的一个问题。这些问题让你关注Redux提供的集中式Store功能， Redux所有的更改都是通过名为Reducers的纯函数完成。

4. 业务逻辑具体位置？ 

MVC	Flux	Redux
Controller处理全部逻辑	Store处理全部逻辑	Reducer处理全部逻辑

       在计算机应用程序中，域逻辑和业务逻辑作为程序的一部分，它将实时的业务规则转换为对数据的创建，存储，显示和修改。在MVC中，Controller作为处理应用程序数据和状态的角色，负责初始化处理请求，但是具体的业务逻辑由Model层决定。

       同样的，了解Flux和Redux的业务逻辑处理是比较有意思的。在Flux中，基于Action的数据更改逻辑在在对应的Store中。Flux中的Store也可以选择性的把部分数据设置为外部模块可访问。然而在Redux中，逻辑处理仍然在Reducer函数中，该函数接收上一个State和Action, 然后返回一个新是State。

5. Debug是如何处理的？

MVC	Flux	Redux
由于双向数据流，导致debug比较困难	使用Dispatcher确保了debug比较简单	单向数据流让Debug变得非常简单

       在MVC应用程序中，由于View和Model之间是双向数据流，导致调试起来比较困难。不过Flux架构处理类似问题就更方便，比如让代码更清晰，更新其他View更方便，新人调试更友好。Flux包含单例Dispatcher, 所有的Actions都通过Dispatcher调度，这种设计避免了级联更新难以调试的问题。Redux没有Dispatcher, 你可能比较困惑Redux是如何处理debug的。

       在Redux中，管理数据和debug变得非常简单，因为整个APP的State都维护在一个Store中。此外，所有组件的State都依赖一个对象树。可以记录到达某个节点而发起的所有Actions，这样就可以从整体上查看应用程序，让debug很轻松。最重要的是，Redux提供了一个非常好的实时代码编辑选项，具有实时debug功能，这个功能让你可以回退和重放debug操作。

6. 可以使用在哪里？

MVC	Flux	Redux
在客户端和服务端框架中都表现较优秀	支持客户端框架	支持客户端框架
支持 前端框架，如Angular JS, Ember,Backbone, Sprout和Knockout 后端框架，如Spring, Ruby on Rails, Django, Meteor.	支持前端框架，如React, AngularJS, Vue.js和Polymer	支持前端框架，如React, AngularJS, Vue.js, Ember,Backbone.js, Meteor和Polymer

        MVC在前端和后端框架中都很流行。有不少前端框架支持采用MVC设计模式，如AngularJS, Ember, Backbone, Sprout, 和Knockout。MVC在后端框架或解决方案也同样是优秀的，如Spring, Ruby on Rails, Django, Meteor等。Flux和Redux在很大程度上是一种前端模式，Flux解决了客户端处理应用程序状态的问题。因此，Angular 2、Vue.js 和 Polymer 等前端框架和库都可以与Flux进行交互。

       在比较Flux和Redux的实用性时，两者差不多。但Redux不仅仅是一个状态管理库，它还给前端应用提供了多项优势，包括确保数据一致性、组件之间共享数据以及为代码组织提供模板。Redux 主要与 React 相关联，但它也可以与其他库很好地协同工作，包括 Vue.js、AngularJS、Ember、Backbone.js、Meteor 和 Polymer。