1.mv*模式
MVC/MVVM简称MC*模式，其中MVVM是从MVC演进而来。
MVC是一种架构设计模式，它通过关注数据界面而分离，来鼓励改进应用程序架构。具体地说，MVC强制将业务数据（Model）与用于界面（Model）隔离，用控制器（Controller）管理逻辑和用于输入。
1.1 MVC结构
在MVC模型中，主要涉及3中角色，Model，View和Controller
- Model
Model负责保存应用数据，和后端交互同步应用数据，或校验数据。Model不涉及用户界面，也不涉及表示层，而是代表应用程序可能需要的独特形式的数据。当Model改变时，它会通知它的观察者（如视图）做出相应的反应。
- View
View是Model的可视化表示，表示当前状态的视图。前端View负责构建和维护DOM元素。View对应用程序中的Model和Controller的了解是有限的，更新Model的实际任务都是在Controller上。
- Controller
负责连接View和Model，Model的任何改变都会应用到View中，View的操作会通过Controller应用到Model中。总的来说，Controller管理了应用程序中Model和View之间的逻辑和协调。
1.2 MVVM的演变
MVVM最大的变化在于VM（ViewModel）代替了C（Controller）。其关键改进是数据绑定，也就是说，View的数据状态发生变化可以直接影响VM，反之亦然。
1.3 MVC的问题
MVC存在一个致命的缺点，这个缺点在项目越来越大、逻辑越来越复杂的时候就非常明显，那就是混乱的数据流动方式。
2. Flux
Flux的核心思想就是数据和逻辑永远单向流动。
在Flux应用中，数据从action何dispathcer，再到store，最终到view的路线是单向不可逆的。store中不能暴露setter的设定加强了数据修改的纯洁性，保证了store的数据确定应用唯一的状态。Flux强调单向数据流，强调谨慎可追溯的数据改动。
2.1 flux的基本概念
一个flux应用由3大部分组成：dispatcher、store和view。其中dispatcher负责分发事件，store负责保存数据，同时响应事件并更新数据，view负责订阅store中的数据，并使用这些数据渲染相应的页面。
尽管它看起来和MVC架构有些像，但其中没有一个职责明确的controller。事实上，flux中存在一个controller-view的角色，但它的职责是负责将view和store进行绑定，并没有传统MVC中的controller需要承担的负责逻辑。
2.1.1 dispatcher和action
flux中的事件由若干个中央处理器来进行分发，这就是dispatcher。
action是一个普通的javascript对象，一般包含type、payload等字段，用于描述一个事件以及需要改变的相关数据。
{
"type": "CLICK"
}
2.1.2 store
在flux中，store负责保存数据，并定义修改数据的逻辑，同时调用dispatcher和register方法将自己注册为一个监听器。这样每当我们使用dispatcher的dispatche方法分发一个action时，store注册的监听器就会被调用，同时得到这个action作为参数。
store一般会根据action的type字段来确定是否相应这个action。若需要相应，则会根据action中的信息修改store中的数据，并触发一个更新时间。
需要特别说明的是，在flux中，store对外只暴露getter而不暴露setter，这意味着在store之外你只能读取store中的数据而不能进行任何的修改。
2.1.3 controller-view
一般来说，controller-view是整个应用最顶层的view，这里不会涉及具体的业务逻辑，主要进行store和view之间的绑定，定义数据更新以及传递的方式。
当store响应某个action并更新数据后，会触发一个更新事件，这个更新事件就是在controller-view中进行监听的。当store更新时，controller-view会重新获取store中的数据，然后调用setState方法触发界面重绘，这样所有的子组件就能获得更新后store中的数据了。
2.2.4 view
view就是用来显示界面的。在flux中，view除了显示界面，还有一条特殊的约定：如果界面操作需要修改数据，则必须使用dispacher分发一个action。事实上，除了这么做，没有其他方法可以在flux中修改数据。