轨道和主干一起工作
我刚开始看MVC结构，首先我看看backbone.js是如何工作的，现在我已经完成了Code School的僵尸轨道 。 我知道我没有深入研究过这个问题，但是我有一个问题要开始。
你可以一起使用这些库吗？
我已经学会了如何在两者中创buildmodels ， views等，但是在创build真正的应用程序时，是否同时使用backbone和rails？
如果是这样…
什么时候使用backbone.js模型与rails模型？
也许我只是走在自己的前面，需要继续练习和做教程，但我似乎无法直接find任何东西。
谢谢！
在开始之前，我会build议看看Thoughtbot的Backbone.js on Rails书籍，这是一个很好的起点，虽然是针对中级到高级的读者。 我买了这本书已经与铁轨工作，但作为一个总的backbone.js初学者，它已经很好地服务了我。
除此之外，将这些框架结合起来，还有一些根本性的问题超出了本书和其他书籍的细节。 下面是我build议你考虑的一些事情，从我自己的配对RoR和backbone.js的经验。 这是一个很长的回答，从你的问题的具体细节上稍微有点偏离，但是我希望它能帮助你理解你所面临的问题。
Rails：Web框架vs API
在rails应用程序的顶部使用backbone.js时，你要面对的第一件事情是如何处理视图，但这只是一个更深层次的问题。 问题的关键在于创buildRESTful Web服务的意义。
Rails的开箱即用，通过标准的HTTP操作，通过在统一的URI（在你的routes.rb文件中定义的）访问的一组资源来构build路由，来鼓励用户创buildRESTful服务。 所以如果你有一个Post模型，你可以：
- 通过向
/posts发送GET请求获取所有/posts - 通过向
/posts/new发送一个GET请求来创build一个新的post，填写表单并将它发送（POST请求）到/posts - 通过向
/posts/123/edit发送一个GET请求来更新一个id为123的/posts/123/edit，填写表单并将它发送给PUT请求posts/123 - 通过向
/posts/123发送DELETE请求来销毁id为123的/posts/123
关于Rails的这个方面，要记住的关键是它基本上是无状态的 ：不pipe我之前做什么，我可以创build一个新的Post只需发送一个带有有效表单数据的POST请求到正确的URI，比如/posts 。 当然，有些警告：我可能需要login（有一个会话cookie识别我），但实质上Rails并不在乎我发送该请求之前正在做什么。 我可以通过更新另一个post，或者通过发送一个有效的动作来提供给我的任何其他资源来跟进它。
Railsdevise的这个方面使得将一个（JavaScript-light）Rails web应用程序变成一个API相对容易：资源将会相似或相同，web框架返回HTML页面，而API（通常）返回数据JSON或XML格式。
Backbone.js：一个新的有状态层
骨干也基于RESTful资源。 无论何时创build，更新或销毁backbone.js模型，您都可以通过标准HTTP操作发送给采用上述RESTful架构的URI。 这使得它非常适合与RoR等RESTful服务集成。
但是这里需要强调的一点是：backbone.js 作为一个API与Rails无缝集成。 也就是说，如果剥离HTML视图并仅使用Rails来提供RESTful资源，集成数据库，执行会话pipe理等，那么它将非常好地与backbone.js为客户端提供的结构码。 许多人认为用这种方式使用rails没有任何问题 ，我认为在很多方面他们是正确的。
这个复杂的问题出现在我们刚刚抛弃的另一部分Rails的问题上：它们的观点和它们所代表的。
有状态的人，无状态的机器
这实际上比起初看起来更重要。 HTML视图表示人类用于访问您的服务提供的RESTful资源的无状态接口。 取消它们让你有两个接入点：
- 对于人类来说：由backbone.js层提供的丰富的客户端接口（有状态的）
- 对于机器：由rails层（无状态）提供的资源导向的RESTful API
请注意，不再有人为的无状态（RESTful）接口。 相比之下，在一个带有API的传统rails应用程序中，我们有更接近这个的东西：
- 人类的HTML资源（无状态）
- 适用于机器的JSON / XML资源（API）（无状态）
后两种访问资源的接口比前两种接近得多。 想想rails的respond_with例子，它利用了相似之处，用统一的方法来包装各种RESTful响应者。
一起工作
我知道，这一切看起来都很抽象。 为了使它更加具体，请考虑以下问题，回到关于让rails和backbone.js一起工作的问题。 在这个问题中，你想要：
- 使用backbone.js创build具有丰富客户端体验的Web服务，使用rails作为后端以JSON格式提供资源。
- 使用
pushState为应用程序中的每个页面提供一个可直接访问的URL（例如/posts/123）（通过将其input到浏览器栏中）。 - 对于这些URL中的每一个，也为没有javascript的客户端提供HTML页面。
对于现代Web服务来说，这些并不是特别的要求，但是它们带来了复杂的挑战。 简而言之，您现在必须创build两个 “以人为本”的层次：
- 有状态的客户端接口（backbone.js模板和视图）
- 无状态HTML资源（Rails HTML视图）
实际上这样做的复杂性导致现今很多人放弃了这两者中的后者，只是提供了丰富的客户端界面。 你决定做什么取决于你的目标和你想达到什么，但是值得仔细考虑这个问题。
作为另一个可能的参考，我会build议看看O'Reilly的RESTful Web服务 。 在一个关于Rails和Backbone.js的问题上推荐一本关于REST的书可能看起来很奇怪，但实际上我认为这是将这些非常不同的框架结合在一起的关键部分，更全面地理解它会帮助你利用两者的优点。
是的，你可以并排使用。 骨干用于存储和操纵客户端浏览器中的数据。 它通常需要一个服务器来交谈和获取数据。 这是Rails进来的地方。你可以有一个Web应用程序没有沉重的客户端代码。 Backbone是用于构build感觉更像应用程序的网站 – 想想Gmail或潘多拉。
我build议先学习Rails。 一旦你可以按照自己的意愿加载和设置静态页面，那么了解Backbone的位置将会更有意义
我使用rails作为后端服务器来服务一个相当大的网站，其中包括一些单页的应用程序（内置骨干）。
我build议在backbone-on-rails的backbone-on-railsgem。 这个想法是，您的Rails服务器将在您的某个视图中作为脚本标记提供骨干应用程序。 您将骨干应用程序本身保存在rails app/assets文件夹中。
Backbone理解轨道路由约定，你只需要给它一个path，可以使用rails generate resource几乎为你生成的json api。
除了模型之间的同步之外，您的骨干应用程序和rails应用程序是相当独立的。 骨干和Rails没有完全相同的MVC模型，但让他们合作是很容易的。
