如果你打算在浏览器中构建复杂的用户界面，那么你可能会发现自己最终发明了构成框架的大部分部件，比如Backbone.js和Sammy.js。所以问题是，你是否在浏览器中构建了一些足够复杂的东西来值得使用它(这样你就不会自己发明同样的东西)。

If what you plan to build is something where the UI regularly changes how it displays but does not go to the server to get entire new pages then you probably need something like Backbone.js or Sammy.js. The cardinal example of something like that is Google's GMail. If you've ever used it you'll notice that it downloads one big chunk of HTML, CSS, and JavaScript when you first log in and then after that everything happens in the background. It can move between reading an email and processing the inbox and searching and back through all of them again without ever asking for a whole new page to be rendered.

It's that kind of app that these frameworks excel at making easier to develop. Without them you'll either end up glomming together a diverse set of individual libraries to get parts of the functionality (for example, jQuery BBQ for history management, Events.js for events, etc.) or you'll end up building everything yourself and having to maintain and test everything yourself as well. Contrast that with something like Backbone.js that has thousands of people watching it on Github, hundreds of forks where people may be working on it, and hundreds of questions already asked and answered here on Stack Overflow.

但是，如果您计划构建的东西不够复杂，不值得花费与框架相关的学习曲线，那么这一切都不重要。如果你仍然在构建PHP、Java或其他网站，而后端服务器仍然在根据用户的请求进行构建网页的所有繁重工作，而JavaScript/jQuery只是在这个过程中锦上添花，那么你将不需要或还没有准备好使用Backbone.js。

是一个MVC设计模式在客户端，相信我。这将为你节省大量的代码，更不用说更干净清晰的代码，更容易维护的代码。 一开始可能有点棘手，但相信我，这是一个很棒的图书馆。

骨干是……

.．.一个非常小的组件库，你可以用来帮助组织你的代码。它被打包成一个JavaScript文件。除去注释，它的实际JavaScript代码不到1000行。它写得很合理，你可以在几个小时内读完整本书。

它是一个前端库，你用一个脚本标签把它包含在你的网页中。它只影响浏览器，很少涉及服务器，除了理想情况下它应该公开一个restful API。

如果您有一个API, Backbone有一些有用的特性可以帮助您与它对话，但是您可以使用Backbone向任何静态HTML页面添加交互性。

骨干是用来…

.．.为JavaScript添加结构。

因为JavaScript不强制执行任何特定的模式，所以JavaScript应用程序很快就会变得非常混乱。任何用JavaScript构建过一些非常简单的东西的人都可能会遇到这样的问题:

我将在哪里存储数据? 我要把函数放在哪里? 我将如何将我的函数连接在一起，以合理的方式调用它们，而不是变成意大利面条? 如何让不同的开发人员可以维护这些代码?

Backbone试图回答这些问题，为您提供:

模型和集合帮助您表示数据和数据的集合。 视图，以帮助您在数据更改时更新DOM。 事件系统，以便组件可以相互侦听。这样可以使组件解耦合并防止面条化。 合理约定的最小集合，因此开发人员可以在相同的代码库上一起工作。

我们称之为MV*模式。模型，视图和可选的额外功能。

骨气轻

尽管最初的样子，Backbone非常轻，但它几乎什么都不做。它所做的是非常有用的。

它提供给你一组你可以创建的小对象，它们可以发出事件并相互监听。例如，您可以创建一个小对象来表示注释，然后创建一个小commentView对象来表示注释在浏览器中特定位置的显示。

您可以告诉commentView监听注释并在注释更改时重新绘制自己。即使您在页面的多个位置显示了相同的注释，所有这些视图也可以侦听相同的注释模型并保持同步。

这种编写代码的方式可以帮助您避免陷入混乱，即使您的代码库因许多交互而变得非常大。

模型

开始时，通常将数据存储在全局变量中，或作为数据属性存储在DOM中。这两种方法都有问题。全局变量之间可能会发生冲突，并且通常形式不好。存储在DOM中的数据属性只能是字符串，您将不得不再次解析它们。存储数组、日期或对象之类的东西，以及以结构化形式解析数据是很困难的。

数据属性是这样的:

<p data-username="derek" data-age="42"></p>

Backbone通过提供一个Model对象来表示数据和相关方法来解决这个问题。假设你有一个待办事项列表，你将有一个模型来表示列表上的每一项。

当您的模型更新时，它会触发一个事件。你可能有一个绑定到特定对象的视图。视图监听模型更改事件并重新呈现自身。

的观点

Backbone为您提供了与DOM对话的View对象。所有操作DOM或监听DOM事件的函数都在这里。

视图通常实现一个渲染函数，该函数可以重绘整个视图，或者可能是视图的一部分。没有义务实现一个呈现函数，但这是一个常见的约定。

每个视图都绑定到DOM的特定部分，因此您可能有一个searchFormView，它只侦听搜索表单，还有一个shoppingCartView，它只显示购物车。

视图通常也绑定到特定的模型或集合。当Model更新时，它会触发视图侦听的事件。视图可能会调用渲染来重绘自己。

同样，当您在表单中输入时，视图可以更新模型对象。所有其他视图都会监听这个模型，然后调用它自己的渲染函数。

这给了我们一个清晰的关注点分离，使我们的代码保持整洁。

渲染函数

你可以用任何你认为合适的方式来实现你的渲染函数。您可以在这里放入一些jQuery来手动更新DOM。

您还可以编译一个模板并使用它。模板只是一个带有插入点的字符串。您将它与JSON对象一起传递给编译函数，并获得一个编译后的字符串，可以将其插入到DOM中。

集合

您还可以访问存储模型列表的集合，因此todoCollection将是todo模型的列表。当集合获得或丢失模型、更改其顺序或更新集合中的模型时，整个集合将触发一个事件。

视图可以侦听集合并在集合更新时更新自身。

例如，您可以向集合添加排序和筛选方法，并使其自动排序。

以及将其联系在一起的事件

应用程序组件尽可能地相互解耦。它们使用事件进行通信，因此shoppingCartView可能监听shoppingCart集合，并在购物车被添加到其中时重绘自身。

shoppingCartView.listenTo(shoppingCart, "add", shoppingCartView.render);

当然，其他对象也可能侦听shoppingCart，并可能执行其他操作，如更新总数，或将状态保存在本地存储中。

视图监听模型，并在模型发生变化时进行渲染。 视图侦听集合并在集合中的项发生变化时呈现列表(或网格或地图等)。 模型侦听视图，以便它们可以更改状态，也许是在编辑表单时。

像这样解耦对象并使用事件进行通信意味着您永远不会陷入困境，并且添加新组件和行为也很容易。您的新组件只需要侦听系统中已经存在的其他对象。

约定

为Backbone编写的代码遵循一组松散的约定。DOM代码属于视图。集合代码属于集合。业务逻辑放在模型中。另一个开发人员继承了您的代码库，将能够开始运行。

总结一下

Backbone是一个轻量级库，可以为代码提供结构。组件是分离的，并通过事件进行通信，因此您不会陷入混乱。您可以轻松地扩展代码库，只需创建一个新对象并让它适当地侦听现有对象即可。您的代码将更干净、更好、更可维护。

我的小书

我非常喜欢骨气，还专门写了一本介绍骨气的书。你可以在线阅读:http://nicholasjohnson.com/backbone-book/

我还把这些材料分解成一个简短的在线课程，你可以在这里找到(存档)。你可以在一天内完成课程。

I have to admit that all the "advantages" of MVC have never made my work easier, faster, or better. It just makes the whole codeing experience more abstract and time consuming. Maintenance is a nightmare when trying to debug someone elses conception of what separation means. Don't know how many of you people have ever tried to update a FLEX site that used Cairngorm as the MVC model but what should take 30 seconds to update can often take over 2 hours (hunting/tracing/debugging just to find a single event). MVC was and still is, for me, an "advantage" that you can stuff.

JQuery和Mootools只是一个工具箱，里面有很多你项目的工具。Backbone就像你的项目的架构或主干，你可以在上面使用JQuery或Mootools构建应用程序。

涉及大量用户交互和许多AJAX请求的web应用程序，需要不时更改，并实时运行(如Facebook或StackOverflow)应该使用MVC框架，如Backbone.js。这是构建好代码的最好方法。

如果应用程序很小，那么Backbone.js就太过分了，尤其是对第一次使用它的用户。

Backbone为您提供了客户端MVC，以及由此隐含的所有优势。