Backbone源码分析——MVC模型

作者：nuysoft/高云/[e-mail]   网址：http://www.cnblogs.com/nuysoft/archive/2012/03/14/2395268.html

代码混乱

前端开发面临以下的问题：

• 数据模型、业务模型不清晰
• 代码复用率低，很多时候是Ctrl+C/V
• 代码的可读性和可维护性低
• 难以满足需求的变化，特别是前端需求的变化

Query在一定程度上改善了这种状态，解决了原生JS代码写起来繁琐的问题，但jQuery毕竟是一个以DOM查找和操作为主的库，这样的定位使得jQuery的大型前端项目中只能作为底层库使用，应用代码依然是杂乱无章，不得不依赖于攻城师的技术水准和职业素养。

而MVC模型通过细分模型、视图、控制器的职责，约定开发方式，让代码开发和管理变得条理、清晰。JS应用程序的本质是事件驱动，而MVC适合于事件驱动的场景，两者不谋而合。MVC在大部分语言的框架中都有实现，JavaScript虽然在这方面起步较晚，但随着前端和JS越来越被认可和重视，JSMVC框架的出现成为必然。

MVC的优点和缺点

MVC可以简化重构、解耦合、提高代码复用、适应变化、易读、较少维护代码、提高可维护性，因为是结构化模块化开发，还可以实现代码自动生成。但是MVC也会导致复杂度上升、运行效率下降。

真的解耦了吗？只是尽可能的解耦，事实上也不可能完全解耦。模型与视图的关系在实际应用中的关系可能更加复杂，视图也不仅仅负责渲染、交互，还可能需要模板引擎、数据解析、适配等等

JSMVC职责划分

M模型

• 业务模型：业务逻辑、流程、状态、规则
• （核心）数据模型：业务数据、数据校验、增删改查

V视图

• （核心）视图：定义、管理、配置
• 模板：定义、配置、管理
• 组件：定义、配置、管理
• （核心）用户时间配置、管理
• 用户输入校验、配置、管理

C控制器/分发器

• （核心）事件分发、模型分发、视图分发
• 不做数据处理、业务处理，及业务无关
• 扩展：权限控制、异常处理等
• C是JSMVC框架的核心，实现集中式配置和管理，可以有多个控制器

工具库

• 主要是异步请求、DOM操作，可以依赖jquery

JSMVC实现探讨

MVC的模型Model、视图View、控制器Control三个相互独立又相互联系，C作为其中的桥梁。MVC作为由来已久的成熟开发模型，已经有经典的实现可控参考，在浏览器和JS这个特定应用场景中，我们做如下探讨：

M模型是自包含的，可以嵌套包含，不会主动引用视图和控制器；可以是简单的JSON对象/数组，也可以用组合模式Composite实现嵌套包含；

V视图是嵌套包含的，可以用组合Composite实现；视图需要引用模型（M-V），一个视图引用一个多个视图，视图会收到模型的通知并自动更新，可以用观察者模式Observer实现；视图需要响应用户的交互，使用浏览器事件模型；

C控制器作为MVC框架关注的核心，采取集中配置的策略（V-C）；可以有多个控制器（C+C），用策略模式Strategy实现；hash事件驱动需要用到浏览器事件模型。

可以看到M模型和C控制器之间没有关联，一般我认为是不需要的；但是在有的框架中实现了M模型和C控制器事件的关联（比如公司在用的Magix），也是一种实践，可以参考。

事件驱动

在浏览器中JSMVC有三种事件驱动方式：

1. hash驱动，通过popstate/hashchange事件驱动控制器（前边有过介绍，后续结合Backbone的Router和History详细讲解它原理、实现、技巧）

2. DOM事件，用来驱动视图（这个我们已经很熟悉了）

3. 模型事件（业务模型事件和数据模型事件），用来驱动模型和模型结合（这个后续结合Backbone的Model讲解）