rails 和主干一起工作 [英] rails and backbone working together

问题描述

我刚刚开始研究 MVC 结构，首先我研究了 backbone.js 是如何工作的，现在我刚刚完成了 僵尸导轨，代码学校.我知道我还没有深入研究这些，但我有一个问题要开始.

I am just starting to look at MVC structure, first i looked at how backbone.js worked, and now I have just completed rails for zombies, by Code School. I know that I haven't delved too far into any of this, but I had a question to begin with.

你能一起使用这些库吗?

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

I have learned how to create models, views, etc in both, but when creating a real application do you use both backbone and rails?

如果是这样...

你什么时候使用 backbone.js 模型和 rails 模型?

When do you use a backbone.js model vs. a rails model?

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

Maybe I am just getting ahead of myself and need to keep practicing and doing tutorials but I couldn't seem to find anything directly on this.

谢谢！

推荐答案

在其他任何事情之前，我建议先看看thoughtbot 的 Backbone.js on Rails 一书，这是一个很好的起点，虽然针对中高级读者.我买了这本书，已经使用过 Rails，但作为一个完全的骨干.js 初学者，它对我很有帮助.

Before anything else I'd suggest taking a look at thoughtbot's Backbone.js on Rails book, which is a great starting point, although aimed at an intermediate to advanced audience. I bought this book having already worked with rails but as a total backbone.js beginner and it has served me very well.

除此之外，结合这些框架还存在一些基本问题，超出了本书和其他书籍所涵盖的细节.下面是我建议你考虑的一些事情，根据我自己将 RoR 和backbone.js 配对的经验.这是一个很长的答案，有点偏离您的问题的具体细节，但我希望它可以帮助您了解您所面临的问题的大局"意识.

Beyond that, there are some fundamental issues with combining these frameworks which go beyond the details covered in this book and other books. Below are some things I'd suggest you think about, from my own experiences pairing RoR and backbone.js. This is a long answer and strays a bit from the specifics of your question, but I hope it might help you out in the "big picture" sense of understanding the problem you're facing.

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

The first thing you confront when using backbone.js on top of a rails application is what to do about views, but this is really just the surface of a much deeper issue. The problem goes to the very heart of what it means to create a RESTful web service.

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

Rails is set up out of the box to encourage its users to create RESTful services, by structuring routing in terms of a set of resources accessed at uniform URIs (defined in your routes.rb file) through standard HTTP actions. So if you have a Post model, you can:

• 通过向 /posts
发送 GET 请求来获取所有帖子
• 通过向 /posts/new 发送 GET 请求、填写表单并发送(POST 请求)来创建新帖子) 到 /posts
• 通过向 /posts/123/edit 发送 GET 请求，填写表单并发送，更新 id 123 的帖子(一个 PUT 请求)到 posts/123
• 通过向 /posts/123
发送 DELETE 请求来销毁 ID 为 123 的帖子

• Get all posts by sending GET request to /posts
• Create a new post by sending a GET request to /posts/new, filling out the form and sending it (a POST request) to /posts
• Update a post with id 123 by sending a GET request to /posts/123/edit, filling out the form and sending it (a PUT request) to posts/123
• Destroy a post with id 123 by sending a DELETE request to /posts/123

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

The key thing to remember about this aspect of Rails is that it is fundamentally stateless: regardless of what I was doing previously, I can create a new Post simply by sending a POST request with a valid form data to the correct URI, say /posts. Of course there are caveats: I may need to be logged in (have a session cookie identifying me), but in essence Rails doesn't really care what I was doing before I sent that request. I could follow it up by updating another post, or by sending a valid action to whatever other resources are made available to me.

Rails 设计的这一方面使得将(Javascript 轻量级)Rails Web 应用程序转换为 API 变得相对容易:资源将相似或相同，Web 框架返回 HTML 页面，而 API(通常)以 JSON 或 XML 格式返回数据.

This aspect of how Rails is designed makes it relatively easy to turn a (Javascript-light) Rails web application into an API: the resources will be similar or the same, the web framework returning HTML pages while the API (typically) returns data in JSON or XML format.

Backbone 也基于 RESTful 资源.每当您创建、更新或销毁 Backbone.js 模型时，您都是通过发送到 URI 的标准 HTTP 操作来实现的，这些 URI 假定采用上述类型的 RESTful 架构.这使其非常适合与 RoR 等 RESTful 服务集成.

Backbone is also based on RESTful resources. Whenever you create, update or destroy a backbone.js model, you do so via the standard HTTP actions sent to URIs which assume a RESTful architecture of the kind described above. This makes it ideal for integrating with RESTful services like RoR.

但这里有一个微妙的点需要强调:backbone.js 与 Rails 无缝集成作为 API.也就是说，如果你去掉 HTML 视图并只使用 Rails 来提供 RESTful 资源、与数据库集成、执行会话管理等，那么它与主干结构很好地集成.js 提供客户端代码.许多人认为 使用 rails 并没有错，而且我认为在很多方面他们都是对的.

But there is a subtle point to be stressed here: backbone.js integrates seamlessly with Rails as an API. That is to say, if you strip away the HTML views and just use Rails for serving RESTful resources, integrating with the database, performing session management, etc., then it integrates very nicely with the structure that backbone.js provides for client-side code. Many people argue that there's nothing wrong with using rails this way, and I think in many ways they are right.

复杂的问题是如何处理我们刚刚丢弃的 Rails 的其他部分:视图及其代表的内容.

The complications arise though from the issue of what to do with that other part of Rails that we've just thrown away: the views and what they represent.

这实际上比最初看起来更重要.HTML 视图表示人类用于访问您的服务提供的 RESTful 资源的无状态界面.去掉它们会给你留下两个接入点:

This is actually more important than it may initially seem. HTML views represent the stateless interface that humans use for accessing the RESTful resources your service provides. Doing away with them leaves you with two access points:

1. 对于人类:由backbone.js 层(有状态)提供的丰富的客户端界面
2. 对于机器:rails 层提供的面向资源的 RESTful API(无状态)

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

Notice that there is no longer a stateless (RESTful) interface for humans. In contrast, in a traditional rails app with an API, we had something closer to this:

1. 人类的 HTML 资源(无状态)
2. 用于机器的 JSON/XML 资源 (API)(无状态)

后两个访问资源的接口在本质上比前两个更接近.想想 Rails 的 respond_with 的例子，它利用相似性来包装各种 RESTful统一方法中的响应者.

The latter two interfaces for accessing resources are much closer in nature to each other than the previous two. Just think for example of rails' respond_with, which takes advantage of the similarities to wrap various RESTful responders in a unified method.

这可能看起来很抽象，我知道离题了.为了尝试使其更具体，请考虑以下问题，这又回到了有关让 rails 和backbone.js 协同工作的问题.在这个问题中，你想:

This might all seem very abstract and beside the point, I know. To try to make it more concrete, consider the following problem, which gets back to your question about getting rails and backbone.js to work together. In this problem, you want to:

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

• Create a web service with a rich client-side experience using backbone.js, with rails as the back end serving resources in JSON format.
• Use pushState to give each page in the app a URL (e.g. /posts/123) which can be accessed directly (by entering it into the browser bar).
• For each of these URLs, also serve an HTML page for clients without javascript.

这些对现代网络服务的需求并不罕见，但它们带来了复杂的挑战.长话短说，您现在必须创建两个以人为本"的层:

These are not unusual demands for a modern web service, but they create a complex challenge. To make a long story short, you now have to create two "human-oriented" layers:

1. 有状态的客户端界面(backbone.js 模板和视图)
2. 无状态 HTML 资源(Rails HTML 视图)

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

The complexity of actually doing this leads many nowadays to abandon the latter of these two and just offer a rich client-side interface. What you decide to do depends on your goals and what you want to achieve, but it's worth thinking about this problem carefully.

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

As another possible reference for doing that, I'd suggest having a look at O'Reilly's RESTful Web Services. It might seem odd to be recommending a book on REST in a question about Rails and Backbone.js, but actually I think this is the key piece that fits these very different frameworks together, and understanding it more fully will help you take advantage of the strengths of both.

这篇关于rails 和主干一起工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！