【混载】基础篇mvc mvvn mvp的区别，一只渣渣前端的内心

前言：相信前端的宝宝们，已经在2016年收到了一万点的伤害与3种主流框架（vue.js angular.js react.js {react-native} ）的视觉冲击。盲目的去追求，不如先从原始的东西开始了解。以下结合大神(阮一峰)的言录与练习，希望能让大家在起飞之前，先有个了解。

MVC

MVC基础化了解.png

MVC模式的意思是，软件可以分成三个部分：

• 视图（View）：用户界面。
• 控制器（Controller）：业务逻辑
• 模型（Model）：数据保存

通信方式.png

• View 传送指令到 Controller
• Controller 完成业务逻辑后，要求 Model 改变状态
• Model 将新的数据发送到 View，用户得到反馈
  所有通信都是单向的。

互动模式

接受用户指令时，MVC 可以分成两种方式。一种是通过 View 接受指令，传递给 Controller。

通信方式.png

另一种是直接通过controller接受指令。

controller接收指令.png

实例：Backbone

实际项目往往采用更灵活的方式，以 Backbone.js 为例。

backbone.png

1. 用户可以向 View 发送指令（DOM 事件），再由 View 直接要求 Model 改变状态。

2. 用户也可以直接向 Controller 发送指令（改变 URL 触发 hashChange 事件），再由 Controller 发送给 View。

3. Controller 非常薄，只起到路由的作用，而 View 非常厚，业务逻辑都部署在 View。所以，Backbone 索性取消了 Controller，只保留一个 Router（路由器） 。

类似java框架里面的mvc，主要还是将页面的代码分层，页面显示HTML（V） + 事件控制（C）+数据模型 +（M），其中c和m都是JS，也就是所谓dom编程

优点：

• 把业务逻辑和展示逻辑分离，模块化程度高。且当应用逻辑需要变更的时候，不需要变更业务逻辑和展示逻辑，只需要Controller换成另外一个Controller就行了（Swappable Controller）。
• 观察者模式可以做到多视图同时更新。

缺点：

• Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，应用逻辑正确性是无法验证的：Model更新的时候，无法对View的更新操作进行断言。
• View无法组件化。View是强依赖特定的Model的，如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的

MVP

MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。

mvp.png

1. 各部分之间的通信，都是双向的。
2. View 与 Model 不发生联系，都通过 Presenter 传递。
3. View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

关键点：

• View不再负责同步的逻辑，而是由Presenter负责。Presenter中既有应用程序逻辑也有同步逻辑。

• View需要提供操作界面的接口给Presenter进行调用。（关键）

• 对比在MVC中，Controller是不能操作View的，View也没有提供相应的接口；而在MVP当中，Presenter可以操作View，View需要提供一组对界面操作的接口给Presenter进行调用；Model仍然通过事件广播自己的变更，但由Presenter监听而不是View。

优点：

• 便于测试。Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中，单元测试的时候就可以完整的测试Presenter应用逻辑的正确性。这里根据上面的例子给出了Presenter的单元测试样例。
• View可以进行组件化。在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做到高度可复用的View组件。

缺点：

• Presenter中除了应用逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。

MVP（Supervising Controller）

上面讲的是MVP的Passive View模式，该模式下View非常Passive，它几乎什么都不知道，Presenter让它干什么它就干什么。而Supervising Controller模式中，Presenter会把一部分简单的同步逻辑交给View自己去做，Presenter只负责比较复杂的、高层次的UI操作，所以可以把它看成一个Supervising Controller。

Supervising Controller模式下的依赖和调用关系：

Supervising Controller.png

因为Supervising Controller用得比较少，对它的讨论就到这里为止。

MVVM

MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。

mvvn.png

• MVVM可以看作是一种特殊的MVP（Passive View）模式，或者说是对MVP模式的一种改良。
• MVVM模式最早是微软公司提出，并且了大量使用在.NET的WPF和Sliverlight中。2005年微软工程师John Gossman在自己的博客上首次公布了MVVM模式。

MVVM的调用关系

MVVM的调用关系和MVP一样。但是，在ViewModel当中会有一个叫Binder，或者是Data-binding engine的东西。以前全部由Presenter负责的View和Model之间数据同步操作交由给Binder处理。你只需要在View的模版语法当中，指令式地声明View上的显示的内容是和Model的哪一块数据绑定的。当ViewModel对进行Model更新的时候，Binder会自动把数据更新到View上去，当用户对View进行操作（例如表单输入），Binder也会自动把数据更新到Model上去。这种方式称为：Two-way data-binding，双向数据绑定。可以简单而不恰当地理解为一个模版引擎，但是会根据数据变更实时渲染。

MVVN调用关系.png

也就是说，MVVM把View和Model的同步逻辑自动化了。以前Presenter负责的View和Model同步不再手动地进行操作，而是交由框架所提供的Binder进行负责。只需要告诉Binder，View显示的数据对应的是Model哪一部分即可。

优点：

• 提高可维护性。解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。
• 简化测试。因为同步逻辑是交由Binder做的，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大大减少了对View同步更新的测试。

缺点：

• 过于简单的图形界面不适用，或说牛刀杀鸡。
• 对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。
• 数据绑定的声明是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。

Angular.js/Vue.js/React.js全部为MVVN框架。敲黑板了！！划重点了。angular.js/vue.js均为数据的双向绑定好的，告诉我你懂了，那么最坑的React.js来了，这是个数据的单项绑定：虚拟DOM、JSX

推荐博客：http://web.jobbole.com/85058/