一、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提高了系统抽象的程度,对于用户来说,它仅仅就是一个动作。