MVC,MVP,MVVM浅析

概述

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 为例。

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

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

3. Controller很是薄，只起到路由的做用，而 View很是厚，业务逻辑都部署在 View。因此，Backbone索性取消了 Controller，只保留一个 Router（路由器） 。

MVP

MVP是对MVC的一种优化或者替代
来看两幅图


两幅图是不一样的，可是对MVC的改进的思想倒是同样的：切断的View和Model的联系，让View只和Presenter（原Controller）交互，减小在需求变化中须要维护的对象的数量。
MVP定义了Presenter和View之间的接口，让一些能够根据已有的接口协议去各自分别独立开发，以此去解决界面需求变化频繁的问题。上面两图都有接口，不过接口的实现和使用细节不同，不过思想上是一致的。
在这里要提到的是，事实上，需求变化最频繁的并不必定是最接近用户的界面，但基本能够肯定的是，最接近用户的界面是由于需求变化而须要最频繁更改的。固然，若是View若是是API而不是UI，那就另说了。
特色能够总结为：

1. 各部分之间的通讯，都是双向的。

2. View与 Model不发生联系，都经过 Presenter传递。

3. 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的富应用上，如今还不过是个初期由膨胀的需求推进的阶段。重要的不是技术会怎么走，而是需求和客观条件会怎么走。

参考资料

MVC，MVP 和 MVVM 的图示
知乎：你对MVC、MVP、MVVM 三种组合模式分别有什么样的理解？