保持你的数据层彻底的与视图层无关，这将会使你创建出更具模块化，可复用与可维护的基础代码。你可以非常容易的在应用程序各个地方复用与扩展模型和集合，而不需要考虑它们所绑定的视图。遵循这个模式使对你项目不熟悉的开发者能迅速的深入到基础代码之中，因为他们会确切的知道哪里发生了渲染，哪里存在有你的应用的所有商务逻辑。
这个模式也执行了单一职责原则，规定了每个类应该具有一个单一的职责，而且它的职责应该封装与这个类之中，因为模型与集合要处理数据，而视图要处理渲染。
路由中的参数
最好的演示这个模式工作方式是举个例子。比如说你需要对搜索页面进行排序，每个搜索页面都允许用户添加两个不同的过滤类型foo和bar，每个类型代表不同的观点。
因此，你的URL结构将会呈现如下：
'search/:foo' 'search/:bar' 'search/:foo/:bar'
现在，所有的路由都用的是同一个试图和模型，这样大多数人喜欢用同一个函数search()来实现。然而，你要是检查过Backbone.js代码的话，你会发祥它里面没有排序的参数映射；这些参数只是从左至右依次传入函数。这样，为了都能统一使用一个函数，你就要停止创建不同的函数正确的来为search()匹配参数。
routes: { 'search/:foo': 'searchFoo', 'search/:bar': 'searchBar', 'search/:foo/:bar': 'search' }, search: function(foo, bar) { }, // I know this function will actually still map correctly, but for explanatory purposes, it's left in. searchFoo: function(foo) { this.search(foo, undefined); }, searchBar: function(bar) { this.search(undefined, bar); },
你也许能想象的到，这个模式可以使路由功能很快膨胀。当我第一次遇到这个问题时，我试图创建了一些用正则表达式定义的解析函数来“神奇”的去匹配参数，当然这个是可以工作的-但这也是有约束条件的。这样，我废弃了这个想法(有时，我仍然可以用Backbone插件来解决)。我进入GitHub中的一个 议题，其中Ashkenas建议应该让所有的参数都和search函数匹配。
上面的代码现在转变为下面维护性更强的样子：
routes: { 'search/:foo': 'searchFoo', 'search/:bar': 'searchBar', 'search/:foo/:bar': 'search' }, search: function(foo, bar) { }, // I know this function will actually still map correctly, but for explanatory purposes, it's left in. searchFoo: function(foo) { this.search(foo, undefined); }, searchBar: function(bar) { this.search(undefined, bar); },
这种模式可以戏剧性的减少路由的过分膨胀。然而，需要注意到它不会服务于不能区别的参数。比如，如果你有两个作为ID的参数，如模式XXXX-XXXX,你不能区分哪个ID是对哪个参数的回应。
model.fetch() 不会清除你的模型
这通常会将那些Backbone.js的新手给绊倒：model.fetch()并不能丢掉你的模型，而是扩展了你的模型的属性。因此，如果你的模型具有属性x,y和z，你获取到y和z，那么x将仍然是模型中的那个x，只有y和z会被更新。下面的例子将这个概念形象化了。
var Model = Backbone.Model.extend({ defaults: { x: 1, y: 1, z: 1 } }); var model = new Model(); /* model.attributes yields { x: 1, y: 1, z: 1 } */ model.fetch(); /* let's assume that the endpoint returns this { y: 2, z: 2, } */ /* model.attributes now yields { x: 1, y: 2, z: 2 } */
PUTs 需要一个 ID 属性
这一条也经常将Backbone.js的新手绊倒。要想在调用.save()的时候让模型发送一个HTTP PUT请求，你的模型需要有一个ID属性集。记得HTTP PUT谓词是设计来做更新的吧，所以发送一个PUT请求，你的模型需要有一个ID，这么做是有意义的。在理想的世界里，你的所有模型都具有一个名为ID的完美的ID属性，但是你从端点接收到的JSON数据可能并不总是具有完美命名的IDs。