复杂的软件必须有清晰合理的架构，否则无法开发和维护！
MVC（Model-View-Controller）最常见的软件架构之一，业界有这广泛应用。
后续衍生出了MVP和MVVM架构。
MVC
MVC模式的意思是，软件可以分为三个部分。
- 视图（View）： 用户界面
- 控制器（Controller）：业务逻辑
- 模型（Model）：数据保存
各个部分之间的通讯方式如下。
- View传送指令到Controller
- Controller完成业务逻辑后，要求Model改变状态
- Model将新的数据发送给View，用户得到反馈
代码展示：
// 模拟 Model, View, Controller
var M = {}, V = {}, C = {};
// Model 负责存放数据
M.data = "hello world";
// View 负责将数据输出到屏幕上
V.render = (M) => { alert(M.data); }
// ontroller 作为一个 M 和 V 的连接
C.handleOnload = () => { V.render(M); }
// 在网页加载好的时候呼叫Controller
window.onload = C.handleOnload;
实例：Backbone
实际项目往往采用更灵活的方式，以Backbone.js为例。
- 用户可以想View发送指令（DOM事件），再由View直接要求Model改变状态。
- 用户也可以直接向Controller发送指令（改变URL触发hashChange事件），再由Controller发送给View
- Controller非常薄，只起到路由的作用，而View非常厚，业务逻辑都部署在View。所有Backbone索性取消了Controller，只保留了Router（路由器）
MVP
MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。
- 各部分之间的通讯，都是双向的
- View与Model不发生联系，都通过Presenter传递
- View非常薄，不部署任何业务逻辑，称为“被动视图”（Passive View），即没有任何主动性，而Presenter非常厚，所有逻辑都部署在这里
MVVM
MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。
唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反应在ViewModel，反之亦然。
Angular和Ember都采用这种模式。
AngularJS 中的 MVVM
- View：专注页面的显示和渲染，在angular中则是包含一堆生命是的视图模板
- ViewModel：它是View和Model的粘合体，负责View和Model的交互和协作，它负责给View提供显示的数据，以及提供了View中Command事件操作Model的途径；在angular中$scope对象充当了这个ViewModel的角色
- Model：与应用程序业务逻辑相关的数据的封装载体，是业务领域的对象，Model并不关心会被如何显示或操作，所以模型也不会包含任何界面显示相关的逻辑。在web页面中，大部分Model都是来自ajax的服务器端数据或者全局的配置对象；而angular中的service则是封装和处理这些与Model相关的业务逻辑的场所，这类的业务服务是可以被多个Controller或者其它service复用的服务
- Controller：并不是MVVM模式的核心元素，但它负责ViewModel对象的初始化，它将组合一个或多个service来获取业务领域Model放在ViewModel对象上，使得应用界面在启动加载的时候可以达到一种可用的状态
View不能直接与Model交互，而是通过$scope这个ViewModel来实现与Model的交互。
对于用户界面的交互Command事件（如ngClick、ngChange等）则会转发到ViewModel对象上，通过ViewModel来实现对于Model的改变。然而对于Model的任何改变，也会反应在ViewModel之上，并且会通过$scope的“脏检查机制”（$digest）来更新到View。从而实现View和Model的分离，达到对前端逻辑MVVM的分层架构。
angular中MVVM模式的实现，以领域Model为中心思维，遵循“分离关注点”设计原则，这也是与jQuery以DOM驱动的思维所不同之处。
