Flux架构

一、MVC和MVVM

   1、MVC（Model View Controller）：MVC不是框架，不是设计模式，也不是软件架构，而是一种架构模式。

• 框架（Framework）：是一个系统的可重用设计，表现为一组抽象的可交互方法。它就像若干类的构成，涉及若干构件，以及构件之间的相互依赖关系、责任分配和流程控制等。比如，C++语言的QT、MFC，Java语言的SSM，Python语言的Django等。
• 设计模式（Design Pattern）：是一套反复使用、多数人知晓的、经过分类的代码设计经验的总结。其目的是为了代码的可重用性、让代码更容易被他人理解、保证代码的可靠性。比如工厂模式、适配器模式等
• 软件架构（Software Architecture）：是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统草图，软件体系结构是构建计算机软件实践的基础。
• 架构模式（风格）：也可以说成是框架模式，一个架构模式描述软件系统里基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。一个架构模式常常可以分解成很多个设计模式的联合使用

（1）MVC把软件工程分为三部分：模式、视图和控制器。这三者各有分工：

• 视图（View）: 负责图形界面展示。前端View负责构建DOM元素，视图层是用户最直接接触到的，用户与之产生交互。View一般都对应着一个Model，可以读取或编辑Model。View接收JSON数据格式的数据。
• 模式(Model) ：负责数据管理， 保存着应用的数据和后端交互同步的数据。Model不涉及表现层和用户界面。它的数据被View所使用， 当Model发生改变时，它会通知视图作出对应的改变。
• 控制器(Contoller) ：作用是连接View和Model。用户在View层的操作会通过Controler实施作用到Model。前端MVC中对于Controller的划分界限不是特别清晰。Controller的本质就是为了控制程序中Model与View的关联。

（2）MVC具有以下优点：

• 独立开发

        MVC支持快速并行的开发。如果使用MVC模型开发任何特定的Web应用程序，那么有可能一个程序员在视图上工作， 而另一个程序员在控制器上工作(创建Web应用序的业务逻辑) 。因此， 使用MVC模型开发的应用程序可以比使用其他开发模式开发应用程序更快。

• 可重复性

        在MVC模型中， 我们可以为模型创建多个视图。面对当下应用程序的新需求日益增加， 采用MVC开发无疑是一个很好的解决方案。而且在这种方法中， 代码重复性小，因为它将数据和业务逻辑从显示中分离出来使用。

• 低耦合

        对于任何Web应用程序， 用户界面往往会根据公司的业务规则频繁更改。很明显，开发人员可以频繁更改Web应用程序， 例如更改颜色、字体、屏幕布局， 以及为手机或平板电脑添加新设备支持等。而且，在MVC模式中添加新类型的视图非常容易，因为模型部分不依赖于视图部分。因此，模型中的任何更改都不会影响整个体系结构。

2、MVVM架构模式

        MVVM 由 Model,View,ViewModel 三部分构成，Model 层代表数据模型，也可以在Model中定义数据修改和操作的业务逻辑；View 代表UI 组件，它负责将数据模型转化成UI 展现出来，ViewModel 是一个同步View 和 Model的对象。

        在MVVM架构下，View 和 Model 之间并没有直接的联系，而是通过ViewModel进行交互，Model 和 ViewModel 之间的交互是双向的， 因此View 数据的变化会同步到Model中，而Model 数据的变化也会立即反应到View 上。

        ViewModel 通过双向数据绑定把 View 层和 Model 层连接了起来，而View 和 Model 之间的同步工作完全是自动的，无需人为干涉，因此开发者只需关注业务逻辑，不需要手动操作DOM, 不需要关注数据状态的同步问题，复杂的数据状态维护完全由 MVVM 来统一管理。

                          

二、Flux简介

        Flux同React一样， 都是出自Facebook。Flux的核心思想是利用单向数据流和逻辑单向流来应对MVC架构中出现状态混乱的问题。

        Flux由3部分组成：Dispatcher、Store和View。其中， Dispatcher(分发器) 用于分发事件； Store用于存储应用状态， 同时响应事件并更新数据； View表示视图层， 订阅来自Store的数据， 渲染到页面。

        Flux的核心是单向数据流， 其运作方式是：

                Action ->Dispatcher ->Store ->View

        整个流程如下：

        (1) 创建Action(提供给Dispatcher) 。

        (2) 用户在View层交互(比如单击事件) 去触发Action。

        (3) Dispatcher收到Action， 要求Store进行相应的更新。

        (4) Store更新， 通知View去更新。

        (5) View收到通知， 更新页面。

从上面的流程可以得知， Flux中的数据流向是单向的， 不会发生双向流动的情况， 从而保证了数据流向的清晰脉络。而MVC和MV VM中数据的流向是可以双向的， 状态在Model和View之间来回“震荡”， 很难追踪和预测数据的变化。

三、深入Flux

         1、Dispatcher简介

             Dispatcher是Flux中的核心概念，它是一个调度中心，管理着所有的数据，所有事件通过它来分发。Dispatcher处理Action（动作）的分发，维护Store之间的依赖关系，负责处理View和Store之间建立Action传递。

        Dispatcher用于将Action分发给Store注册的回调函数，它与普通的发布-订阅模式（pub-sub）有两点不同：

        （1）回调函数不是订阅到某一个特定的事件或频道，每个动作会分发给所有注册的回调函数

        （2）回调函数可以指定在其他回调函数之后调用

        Dispatcher通常是应用级单例，一个应用中只需要一个Dispatcher即可

        2、Action简介

        Action 可以看作是一个交互动作， 改变应用状态或View的更新， 都需要通过触发Act n来实现。Action执行的结果就是调用了Dispatcher来处理相应的事情。Action是所有交互的入口， 改变应用的状态或者有View需要更新时就需要通过Action实现。

Action是一个JavaScript对象， 用来描述一个行为， 里面包含了相关的信息。

       3、Store和View简介

        Store包含应用状态和逻辑， 不同的Store管理不同的应用状态。Store负责保存数据和定义修改数据的逻辑，同时调用Dispatcher的register()方法将自己设为监听器。每当发起一个Action（动作）去触发Dispatcher，Store的监听器就会被调用， 用于执行是否更新数据的操作。 如果更新了， 那么View中将获得最新的状态并更新。

Store在Flux中的特性是， 管理应用所有的数据； 只对外暴露getter方法， 用于获取Store的数据， 而没有暴露setter方法， 这就意味着不能通过Store去修改数据。如果要改Store的数据， 必须通过Action动作去触发Dispatcher实现。

只要Store发生变更，它就会使用emit()方法通知View更新并展示新的数据。

四、Flux的缺点

        Flux的缺陷主要体现在增加了项目的代码量， 使用Flux会让项目带入大量的概念和文件；单元测试难以进行， 在Flux中， 组件依赖Store等其他依赖， 使得编写单元测试非常复杂。

五、Flux架构小结

        Flux是一种架构模式， 它的出现可以说是MVC的“替代方案”， 它是于复杂应用中数据流管理的一种方案。

        Flux的核心思想是“单向数据流”， 加之其“中心化控制”特点得以让题据改支源头变得可控， Flux架构追踪数据改变的复杂程度相对于MVC简单许多；Flux让View保持高度整洁， 无须关注太多逻辑， 只需关注传入的数据；Flux的Action提高了系统抽象的程度，对于用户来说，它仅仅就是一个动作。