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