导轨和骨干一起工作

Posted 2023-02-24

【中文标题】导轨和骨干一起工作

【英文标题】：rails and backbone working together

【发布时间】：2012-08-08 18:06:36

【问题描述】：

我刚开始研究 MVC 结构，首先我研究了 backbone.js 的工作原理，现在我刚刚完成了 Code School 的 rails for zombies。我知道我没有深入研究任何这些，但我有一个问题要开始。

可以一起使用这些库吗？

我已经学会了如何在两者中创建models、views 等，但是在创建真正的应用程序时，您是否同时使用主干和导轨？

如果是这样……

您什么时候使用backbone.js 模型与rails 模型？

也许我只是超前了，需要继续练习和做教程，但我似乎无法直接找到任何关于此的内容。

谢谢！

【参考方案1】：

首先，我建议先看看thoughtbot 的Backbone.js on Rails 书，这是一个很好的起点，尽管它针对的是中高级读者。我买这本书时已经使用过 Rails，但作为一个完全的骨干.js 初学者，它对我很有帮助。

除此之外，将这些框架结合起来还存在一些基本问题，这些问题超出了本书和其他书籍所涵盖的细节。以下是我建议您考虑的一些事情，来自我自己的经验，将 RoR 和主干.js 配对。这是一个很长的答案，与您的问题的细节有些偏离，但我希望它可以帮助您从“大局”的角度理解您面临的问题。

Rails：Web 框架与 API

在 Rails 应用程序上使用backbone.js 时，您面临的第一件事是如何处理视图，但这实际上只是更深层次问题的表面。问题的核心是创建 RESTful Web 服务的意义。

Rails 开箱即用，鼓励其用户创建 RESTful 服务，方法是根据一组通过标准 HTTP 操作在统一 URI（在您的 routes.rb 文件中定义）访问的资源来构建路由。所以如果你有Post 模型，你可以：

通过发送GET 请求到/posts 获取所有帖子 通过向/posts/new 发送GET 请求创建新帖子，填写表格并将其（POST 请求）发送至/posts 通过向/posts/123/edit 发送GET 请求更新ID 为123 的帖子，填写表格并将其（PUT 请求）发送到posts/123 通过向/posts/123 发送DELETE 请求来销毁ID 为123 的帖子

关于 Rails 的这一方面要记住的关键是它基本上是无状态：无论我以前做什么，我都可以通过发送POST 来创建一个新的Post使用有效的表单数据向正确的 URI 请求，例如 /posts。当然有一些警告：我可能需要登录（有一个会话 cookie 来识别我），但本质上 Rails 并不真正关心我在发送该请求之前在做什么。我可以通过更新另一个帖子来跟进它，或者通过向我可以使用的任何其他资源发送有效的操作。

Rails 设计的这一方面使得将（javascript-light）Rails Web 应用程序转换为 API 相对容易：资源将相似或相同，Web 框架返回 html 页面，而 API（通常）返回 JSON 或 XML 格式的数据。

Backbone.js：一个新的有状态层

Backbone 也基于 RESTful 资源。每当您创建、更新或销毁一个backbone.js 模型时，您都可以通过发送到假定上述类型的RESTful 架构的URI 的标准HTTP 操作来执行此操作。这使其非常适合与 RoR 等 RESTful 服务集成。

但这里有一点需要强调：backbone.js 作为 API 与 Rails 无缝集成。也就是说，如果你去掉 HTML 视图，只使用 Rails 来提供 RESTful 资源、与数据库集成、执行会话管理等，那么它与骨干结构的集成非常好.js 提供客户端代码。很多人认为there's nothing wrong with using rails this way，我认为他们在很多方面都是对的。

问题在于如何处理我们刚刚丢弃的 Rails 的其他部分：视图和它们所代表的内容。

有状态的人，无状态的机器

这实际上比最初看起来更重要。 HTML 视图表示人类用于访问您的服务提供的 RESTful 资源的无状态接口。取消它们会给您留下两个访问点：

对于人类：backbone.js 层提供的丰富的客户端接口（有状态） 对于机器：rails 层提供的面向资源的 RESTful API（无状态）

请注意，人类不再有无状态 (RESTful) 接口。相比之下，在带有 API 的传统 Rails 应用程序中，我们有一些更接近于这样的东西：

人类的 HTML 资源（无状态） 机器的 JSON/XML 资源 (API)（无状态）

后两个用于访问资源的接口在本质上比前两个更接近。以 rails 的 respond_with 为例，它利用相似性将各种 RESTful 响应者封装在一个统一的方法中。

一起工作

我知道，这一切似乎都非常抽象而且题外话。为了使它更具体，请考虑以下问题，这又回到了您关于让 rails 和backbone.js 一起工作的问题。在这个问题中，你想要：

使用backbone.js 创建一个具有丰富客户端体验的Web 服务，并将rails 作为JSON 格式的后端服务资源。 使用pushState 为应用中的每个页面提供一个URL（例如/posts/123），该URL 可以直接访问（通过在浏览器栏中输入）。 对于这些 URL 中的每一个，还为没有 javascript 的客户端提供 HTML 页面。

这些对于现代 Web 服务的需求并不罕见，但它们带来了复杂的挑战。长话短说，您现在必须创建两个“以人为本”的层：

有状态的客户端界面（backbone.js 模板和视图） 无状态 HTML 资源（Rails HTML 视图）

实际执行此操作的复杂性导致如今许多人放弃这两者中的后者，而只提供丰富的客户端界面。你决定做什么取决于你的目标和你想要达到的目标，但值得仔细考虑这个问题。

作为另一个可能的参考，我建议看看 O'Reilly 的 RESTful Web Services。在一个关于 Rails 和 Backbone.js 的问题中推荐一本关于 REST 的书可能看起来很奇怪，但实际上我认为这是将这些非常不同的框架结合在一起的关键部分，更全面地理解它将帮助你利用两者的优势。

【讨论】：

哇，这太棒了。稍微澄清一下：在合作部分中，您概述的解决方案的想法是在主页上有一个主干应用程序，例如使用 AJAX 或其他方法访问 JSON 数据而不是视图，但也使可以通过输入 URL 有机地访问的 HTML 视图？再次感谢您的彻底回答，我非常感谢！

很高兴你喜欢它！是的，你谈到了关键点，我没有试图具体回答，因为那将是另一个完全不同的讨论。这真的取决于你正在构建什么样的应用程序。例如，对于我现在正在做的一个应用程序，我们决定只为我们的资源的 GET 请求提供（无 js 的）HTML 页面。如果用户想要创建或更新这些资源，他们必须通过丰富的接口（或可能直接访问 API）。这是一个设计选择。你也可以选择放弃 no-JS 支持，但仍然有你的资源的 URL，那么你就不需要 rails 视图了。

很好的答案。如果我可以+2，我会的。感谢您花时间整理出如此完整、周到的回复。

不客气！请将链接传递给对此主题感兴趣的任何其他人。

您不需要添加哈希值。您只需要一个（Rails）路由来呈现应用程序的相同根视图，然后 Backbone（启用 pushState）会将路径识别为 Backbone 路由并呈现适当的（Backbone）视图。如果浏览器不支持 pushState，Backbone 会识别它并重定向到以哈希为前缀的路径。

【参考方案2】：

是的，您可以同时使用两者。 Backbone 用于在客户端浏览器中存储和操作数据。它通常需要一个服务器来与 通信并从中获取数据。这就是 Rails 的用武之地。您可以拥有一个没有繁重客户端代码的 Web 应用程序。 Backbone 用于构建更像应用程序的网站——想想 Gmail 或 Pandora。

我建议先学习 Rails。一旦您可以根据需要加载静态页面并设置样式，那么了解 Backbone 的位置将更有意义

【参考方案3】：

我使用 Rails 作为后端服务器来为一个相当大的网站提供服务，其中包括一些单页应用程序（内置主干）。

我建议使用backbone-on-rails gem。这个想法是，您的 Rails 服务器将在您的一个视图中将主干应用程序作为脚本标记提供服务。您将主干应用程序本身保存在 rails app/assets 文件夹中。

Backbone 了解 Rails 路由约定，您只需为其提供一个 json api 的路径，rails 几乎可以使用rails generate resource 为您生成。

除了模型之间的同步之外，您的主干应用程序和 Rails 应用程序是相当独立的。 Backbone 和 Rails 没有完全相同的 MVC 模型，但让它们合作很容易。