概述
M -V- X 本质都是一样的 重点还是在于M-V 的桥梁
要靠 X来牵线。
X的模式之间不同 主要是 M与V 的数据传递的流程不同。
数据传递的流程不同来源于运行环境技术栈能够做到的事情不同。
所以无论是复杂化 简单化 还是修改流程，基本都是因为技术栈变化了 对应做的调整。
在相同技术栈下 能够实现的各种 X都可以是大同小异的。
在不同技术栈下 相同的X可能实现都大相径庭，仅有非常抽象的流程类似。
前端框架演变
MVC
视图（
View）：用户界面。控制器（
Controller）：业务逻辑模型（
Model）：数据保存MVC的一般流程是这样的：View（界面）触发事件–》Controller（业务）处理了业务，然后触发了数据更新–》不知道谁更新了Model的数据–》Model（带着数据）回到了View–》View更新数据
缺陷：在MVC，当你有变化的时候你需要同时维护三个对象和三个交互，这显然让事情复杂化了。
实例：Backbone
实际项目往往采用更灵活的方式，以 Backbone.js 为例。
用户可以向
View发送指令（DOM 事件），再由View直接要求Model改变状态。用户也可以直接向
Controller发送指令（改变 URL 触发hashChange事件），再由Controller发送给View。Controller非常薄，只起到路由的作用，而View非常厚，业务逻辑都部署在View。所以，Backbone索性取消了Controller，只保留一个Router（路由器） 。
MVP
MVP是对MVC的一种优化或者替代
来看两幅图
两幅图是不同的，但是对MVC的改进的思想却是一样的：切断的View和Model的联系，让View只和Presenter（原Controller）交互，减少在需求变化中需要维护的对象的数量。MVP定义了Presenter和View之间的接口，让一些可以根据已有的接口协议去各自分别独立开发，以此去解决界面需求变化频繁的问题。上面两图都有接口，不过接口的实现和使用细节不一样，不过思想上是一致的。
在这里要提到的是，事实上，需求变化最频繁的并不一定是最接近用户的界面，但基本可以确定的是，最接近用户的界面是因为需求变化而需要最频繁更改的。当然，如果View如果是API而不是UI，那就另说了。
特点可以总结为：
各部分之间的通信，都是双向的。
View与Model不发生联系，都通过Presenter传递。View非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而Presenter非常厚，所有逻辑都部署在那里。
MVVM
ViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel间没有了MVP的界面接口，而是直接交互，用数据“绑定”的形式让数据更新的事件不需要开发人员手动去编写特殊用例，而是自动地双向同步。数据绑定你可以认为是Observer模式或者是Publish/Subscribe模式，原理都是为了用一种统一的集中的方式实现频繁需要被实现的数据更新问题。
比起MVP，MVVM不仅简化了业务与界面的依赖关系，还优化了数据频繁更新的解决方案，甚至可以说提供了一种有效的解决模式。
Angular 和 Ember 都采用这种模式。
实际上，现在Web MVVM主要并不是用在了Web或者Wap上，而是移动App上。按照前面的说法，只可能是：HTML+JS比原生在一些场景上更适合Native
在移动App上比Web上更适合使用MVVM
哪怕是Native开发，实际上iOS的开发上也是用类似的数据绑定的方式的。这里也不深究了，毕竟我也不算懂iOS。
要说的是，在Web MVVM或者Web的模式上，也就是Web的富应用上，现在还不过是个初期由膨胀的需求推动的阶段。重要的不是技术会怎么走，而是需求和客观条件会怎么走。
