前端Backbone源码解读（一）
happylife 2016-08-29
MVC?
MVC是一种GUI软件的一种架构模式。它的目的是将软件的数据层(Model)和视图(view)分开。Model连接数据库，实现数据的交互。用户不能直接和数据打交道，而是需要通过操作视图，然后通过controller对事件作出响应，最后才得以改变数据。最后数据改变，通过观察者模式更新view。(所以在这里需要用到设计模式中的观察者模式)
Smalltalk-80 MVC
Smalltalk-80是早期的对MVC模式的一种实现。这种模式的目的是分离应用的内部逻辑和用户的交互界面。在书中讲述了这种模式有几个特点：
- 用户操作界面(view和controller)和数据层(Model)是分离的。
- 数据的呈现是由view和controller完成的。它们两者没有明显的分界。(controller并非必须，可以用其他替代，因此就有了MVP和MVVM。)
- controller的任务就是处理用户操作view发出的事件。比如点击，输入等等。
- model一旦发生改变就会通过观察者模式更新view。
后端
我接触过python的flask和node的express框架，都是以MVC的形式来组织的。V层用模板引擎呈现页面，用户对V层做操作，触发订阅好的事件，然后路由操作数据库，最后重新呈现页面，达到更新的效果。个人感觉对后端来说，MVC的概念会更加直接和清晰。
前端backbone
废话很多，下面直接进入正题了。MVC在前端开始流行(当然现在什么MVVM更火)还是backbone的功劳。backbone的源码相对于其他框架来说很短(1.3.3版本的有2027行)。所以虽然感觉用backbone写应用很不容易，但是认真去读backbone源码还是可以加读懂不少的。我会分三篇文章去分析backbone的源码。以下：
- backbone的总结架构和Events
- model & collection & view
- sync & router & history
我看过很多人想写backbone的源码分析，写得都很不错，看了很有收获,然而...大都都是些了一篇两篇就停更了，悲伤的故事...希望我能够坚持下来吧。
总体架构
终于开始啦!backbone里代码结构和官方文档里面的组织方式几乎是一模一样的，所以把官方文档当成索引来读也是很方便的~代码的整体架构如下：
(function(factory) {
// 在这里是backbone模块化的一个接口。支持AMD，CMD和全局变量模式。代码很好理解。
})(function(root, factory, _, $) {
// 各种参数和函数的定义
Backbone.noConflict = function(){};
var Events = Backbone.Events = {};
// 然后是各种Events方法的添加
// Events在Backbone里面非常重要，Model，Collection和View都extend了它。（不知道怎么说才自然...）所以他们都可以发起订阅事件，发起事件。当然，用户也可以自己拿自己的对象拓展一下，那样也可以订阅发起事件了~
var Model = Backbone.Model = function(){};
_.extend(Model.prototype, Events, {
// 这里是各种对Model.prototype的拓展，定义各种方法
});
var Collection = Backbone.Collection = function(){};
_.extend(Collection.prototype, Events, {
// 这里是各种对Collection.prototype的拓展，定义各种方法
});
var View = Backbone.View = function(){};
_.extend(View.prototype, Events, {
// 这里是各种对View.prototype的拓展，定义各种方法
});
Backbone.sync = function(){};
Backbone.ajax = function(){};
var Router = Backbone.Router = function(){};
_.extend(Router.prototype, Events, {
// 这里是各种对Router.prototype的拓展，定义各种方法
});
var History = Backbone.History = function(){};
_.extend(History.prototype, Events, {
// 这里是各种对History.prototype的拓展，定义各种方法
});
// 用History定义实例
Backbone.history = new History;
// 接下来是helper函数extend
var extend = function(){};
Model.extend = Collection.extend = Router.extend = View.extend = History.extend = extend;
// 其他的还有urlError，warpError函数
return Backbone;
}); 在这一小节我顺便把除了model & collection & view & sync & router & history相关之外的都讲了先吧
noConflict
防止冲突，如果自己本身全局就有Backbone，可以用noConflict解决冲突。不过，一般都不会有人起一个会冲突的名字吧...
var previousBackbone = root.Backbone;
Backbone.noConflict = function() {
root.Backbone = previousBackbone;
return this;
}; extend
这个函数返回了一个对象。这个对象的属性，方法，构造函数，原型都有了定义，很完整。
var extend = function(protoProps, staticProps) {
var parent = this;
var child;
// 如果protoProps有构造函数就给child吧。
if (protoProps && _.has(protoProps, 'constructor')) {
child = protoProps.constructor;
} else {
// 如果没有就用parent的。
child = function(){ return parent.apply(this, arguments); };
}
// 把parent和staticProps的属性方法给child吧。
_.extend(child, parent, staticProps);
// 定义child的prototype。child是继承自parent的。这里不直接调用构造函数。
child.prototype = _.create(parent.prototype, protoProps);
child.prototype.constructor = child;
child.__super__ = parent.prototype;
return child;
}; 这个函数理解起来并不困难，但在整个backbone里面很关键。因为不管是Model还是Collection还是Router等都需要Events的方法来做一些事件相关的操作。
// 大家都需要extend这个方法。 Model.extend = Collection.extend = Router.extend = View.extend = History.extend = extend;
Events
backbone的Events和nodejs的EventEmmiter有很多类似的地方。其实本质上就是一个发布订阅模式的算是比较常见的实现。
开始这段代码我看了一个早上，不长，但是里面有一点绕。后来看到这篇文章之后(他讲得很棒!选取的角度非常不错!但是停!更!了!...悲伤...)就开始理解了。但由于版本不同，差别还是不少。
这里我打算从两个方面来讲解这个Events，一个是内部对象，一个是主要方法。事实上，在传统的发布订阅模式中，主要也是这两个组成部分。由内部对象来管理所有的事件，由方法来做订阅，发布，取消等的操作。具体来说，就是通过Events当中的this的各个属性，来存储，管理事件。而外部，则通过on，off，listenTo等方法来操作这些属性。
具体的bakcbone代码可以看这里。在文中不会大段大段贴代码。不过强烈建议对照着看。
Events中的this
Events中的内部对象this起得作用是管理所有的事件，所有的监听和所有的被监听。可以尝试下把官方的todo范例的view里输出一下console.log(this)，其中的_listeningTo, _events, _listenId, _listeners都是Events带来的内部函数的属性。下面的关键方法，其实一定程度上都是操作这些内部属性的方法。其中有一点需要注意，并不是每一个有Events方法的对象都会有着四个属性。记住一点，只有需要的时候才会创建，不需要的时候是没有的。设计模式在这里有很多涉及，可以去了解一下。下面讲讲这四个内部属性。
- _listeningTo: 当前对象所监听的对象。对象里面是一个或多个以被监听对象的_listenId为名字的对象。每一个对象结构如下：
{
count: 5, // 监听了几个事件
id: 13, // 监听方的id
listeningTo: Object, // 自身相关的一些信息（很有趣，里面可以无限点击下去，因为引用了自身。不知道有什么用意...）
obj: child, // 被监听的对象
objId: "12" // 被监听对象id
} _listenId: 监听与被监听时候的标示 _listeners: 监听该对象的对象信息(有点绕，就是指“看着”它的对象)结构与_listeningTo类似。 _events: 一般是被监听对象或者说是用了on的对象才有的。一个name带有几个对象是一般常见的情况。这里面有很多循环引用的地方，细细看才不会被看绕啊。
Events中的关键方法与函数
关键方法是写代码的时候用到的方法，算是一种接口，可以对内部对象的属性做出改变。
在看backbone的时候，(其实不单只backbone，大部分写得良好的，复用率高的代码)，总会觉得很繁琐。但其实这才是良好代码应该有的样子：函数分工明确，各司其职，没有重复代码。很值得学习。虽然略微增加了阅读的难度...要认真分析函数在哪里调用，数据的流向等等才能很好地理解。比如一个on函数，里面调用了internalOn，internalOn函数传入了一个onApi，调用了eventsApi，onApi在eventsApi里面调用，往_events里面添加了新的事件。这只是一个例子，其他的其实都类似。
eventsApi(辅助函数)
这是一个有趣的函数，它只是提供一个api接口，起到分流的作用。函数中根据不同的name的形式作出不同的调用调整。使得代码得到很好的复用。传入的参数及其作用是：
- iteratee 实际真正要调用的函数
- events 事件，有很多情况中传入的是this._events
- name 自己起的名字或者之前起的名字，代表了一个事件
- callback 回调函数，触发事件时触发
- opts 参数，在iteratee函数的内部有自己的作用
在进入它的函数的时候，会有一个判断，把整一个函数内部分成三个部分，分别处理三种不同的情况。三种不同的情况分别是name是一个对象，一个有空格的字符串，一个普通字符串。根据三种不同的情况，对name进行处理，然后调用iteratee函数。
on
on方法的实质是把事件添加到this._events里面，非常直观。但是由于函数调用感觉好像复杂了。在on里面调用了internalOn，internalOn把函数onApi传给了eventsApi，eventsApi里面调用了onApi，然后就把事件的信息push进_events中。
onApi(辅助函数)
这个函数很简单，处理的事情就是往this._events里面push进相应的事件。一般是有添加进新函数的时候才会调用到这个函数。值的注意的是描述一个事件的时候往往还需要一些其他的参数，这时候就需要options来提供了。
off
off和on其实类似，只是把上面的onApi换成了offApi函数，其他都是大体一致的。要看offApi的具体实现可以看下面。
offApi(辅助函数)
取消事件有几种情况。当stopListening调用它的时候就不需要留下任何监听函数，而用off的时候则还需要留下一些不应该删除的函数。删除分两步，第一步是删除自己的，把监听该对象的listener删除。再第二部就是把那一个listener的listeningTo删除。其实这种删除方式和后端数据库的一些操作非常相似。删除是两个方面的。
listenTo
其实看上去繁琐，这个函数的作用就是构建_listeningTo的一个过程。这个对象具体的形式在上面已经讲解过了。
stopListening
这个函数就是把对象所有监听的都清除掉。这个函数的内部原理也很简单，就是把_listeningTo遍历一遍)，最后调用off取消掉所有的被监听者listeners里面的相应的监听者。
once & listenToOnce
两者内部很相近，都是调用eventsApi把要执行的函数onceApi传进去。差别在于once是最后是调用on，而listenToOnce最后调用listenTo。他们都是调用了一次就off掉的，原理在下面的onceMap介绍里面有讲解。
onceMap(辅助函数)
这个地方不好懂的地方是这个offer。offer这里是一个特殊的options。如果之前调用的once，offer就是off，如果之前调用的是listenToOnce就是stopListening。意思都是取消放弃监听。然后才调用回调函数。这样做就达到“一次性”事件的要求。这里还保留了一个_callback函数的目的是什么呢?
once._callback = callback;
这篇文章里说了，在offApi里面有这么一行判断
callback !== handler.callback._callback
根据这个判断，就会让一次性函数不会得以保留，这样也就达到了用完一次就删除的目的。这样在调用offer的时候才得以删除之。
trigger
trigger函数和之前的一样，也是委托了eventsApi，把辅助函数传进去了。具体可以看下面 triggerApi & triggerEvents有详细介绍。
triggerApi & triggerEvents (辅助函数)
这两个trigger的辅助函数是这样工作的。在trigger函数里面把triggerApi函数传给了eventsApi调用，而triggerApi调用了triggerEvents。在trigger里面先是把参数取出来。后来参数会传到triggerApi里面。然后会开始判断是否有这个事件啊，还有这个事件是不是“all”事件啊，等等。然后再调用triggerEvents，在这个函数里面就是循环执行回调函数。(原本代码注释写的迷之优化(difficult-to-believe)其实很好理解，所谓能够枚举就枚举嘛，总是或多或少能优化的。)
总结
