MV*结构的发展

一，MVC

Model模型，View视图，Controller控制器

理解：

MVC就是将最原始的繁琐流程进行模块化，Model负责从数据库取数据，View负责展示获取的数据，用户在View进行操作，Controller处理用户交互，负责主要的业务逻辑处理（例如用户点击事件，Controller修改Model的数据，然后View通过观察者模式检测到Model数据发生变化，然后刷新页面）

缺点：

• MVC是单向的
• View依赖特定的Model，无法组件化
• View和Controller耦合度高，脱离Controller，View难以独立应用
• 主要业务逻辑都在Controller中，变得很重

二，MVP

Model模型，View视图，Presenter控制器

理解：

MVP是双向的，在MVC的基础上进一步完善，View和Model完全没有联系，所有的操作都必须通过Presenter中转。View向Presenter发起请求，Presenter修改Model，Model修改完后反馈给Presenter，然后Presenter调用View的相关接口刷新页面。View层不再像MVC那样监听Model改变了。

优点：

• View可以组件化，不需要了解业务逻辑，只需要提供接口给Presenter
• 方便测试

三，MVVM

Model模型，View视图，ViewModel封装的P层逻辑与数据对象

理解：

在MVP的基础上进一步完善，ViewModel是把MVP的Presenter中调用View的接口同步数据变化的重复工作抽象出来，做成一个binder模块，实现了双向数据流。用户只需要操作数据即可。即用户只需绑定好关系，则不管哪一端的数据改变，都会自动同步到另一端。但View和Model依旧是没有关联。

因此vue属于MVVM框架，但并不完全，因为vue中view和model还可以通过ref来操作关联，二者并非毫无关联。

缺点：

• 由于绑定较随意简单，View对绑定Model进行修改可能会造成其他View也被修改的连锁反应，由此导致代码的可预测性较差（无法判断连锁反应的数据修改是由谁造成的）

四，Flux

理解：

对于MVVM双向数据绑定可能会造成的连锁反应问题，所以提出了Flux结构（组件化 + 单向数据流），他的本质还是MVC结构，只是更加简单和清晰。

组件化：由于MVC中，Model要存储数据，还要存储UI状态；同样Controller既要控制业务逻辑，也要处理交互等事件。因此将这些部分抽离出来，和View结合在一起，就成了组件。这样大大提高了代码的可读性和复用性。

单向数据流：Flux主要通过单向数据流提高代码的可预测性。单向数据流主要引入了Store（每个程序可以有多个Store，存储应用程序状态的不同部分）、Action（包含对应的type和payload，用来发起修改Store的请求）、Dispatcher（接收Action，通过回调函数完成Store数据的修改）3个概念。

Store对View是只读的，只有Dispatcher可以通过Store的回调函数修改他的内容

当发起一个Action改变Store数据时，会发送一个事件，View通过监听这个事件完成页面UI的刷新。如果需要再次刷新，则需要再次发起一个新的Action，因此整个过程是单向的。

• 修改流程1：用户在View上操作并修改Store的数据，则需要先发起一个Action（包含对应的type和payload），然后Dispatcher当接收到Action，会通过回调函数调用所有Store的，完成数据的修改。View完成页面UI刷新（即View => Action => Dispatcher => Store => View）
• 修改流程2：服务器或者web API可以直接发起Action，并通过Dispatcher修改Store的数据，完成View的刷新（即 Action => Dispatcher => Store => View）

缺点：

• 他采用多Store，各个Store之间可能存在数据依赖，协同管理上存在一定的设计缺陷（因此Redux的实现避免这一问题）