MVC、MVP、MVVM的分析

MVC模式（Model–view–controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller），该模型在1978年提出的，这三个部分可以是对复杂度的简化，使结构更加直观。
- 控制器（Controller）- 负责转发请求，对请求进行处理。
- 视图（View） - 界面设计人员进行图形界面设计。
- 模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
具体的形式为：
可以看出来所有的通信的方式都是单向的。

接受用户指令时，MVC可以分成两种方式，
- 一种是通过View接受指令，传递给Controller。
- 一种是直接传递给Controller，然后指向Model，再改变View

这个例子在原文中连接失效了，但是模式就是上面的那种互动的两种模式。
用户可以向View发送指令DOM时间，再由View直接要求Model改变状态。
用户也可以直接向Controller发送指令(改变URL触发hashChange事件)，再由Controller发送给View。
Controller非常薄，只是起到了路由的作用，而View非常厚，业务逻辑都在View，所以，BackBone索性取消了Controller，只是保留了一个Route(路由器)。

MVP 全称：Model-View-Presenter ；MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。
区别在于，在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。
在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。在MVC模型里，更关注的Model的改变，而同时有多个对Model的不同显示，即View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
具体的形式为：
1. 各个部分之间的通信，都是双向的。
2. View和Model之间不发生关系，都是通过Presenter传递
3. View非常厚，不部署任何业务逻辑，称之为"被动视图"(Passive View)，即没有任何主动性，而Presenter非常厚，所有的逻辑都部署在那里。

由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。
还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。

MVVM 模式将Presenter改名为ViewModel，基本上与MVP模式完全一致。
MVVM有助于将图形用户界面的开发与业务逻辑或后端逻辑（数据模型）的开发分离开来，这是通过置标语言或GUI代码实现的。MVVM的视图模型是一个值转换器，[1] 这意味着视图模型负责从模型中暴露（转换）数据对象，以便轻松管理和呈现对象。在这方面，视图模型比视图做得更多，并且处理大部分视图的显示逻辑。
具体的形式为：
1. 它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。Angular 和 Ember 都采用这种模式。