Ruby on Rails基本概念摘要 [英] Summary of Ruby on Rails fundamental concepts

问题描述

作为Rails的新手，我很难找到一个提供Ruby on Rails摘要的网站或参考。我基本了解MVC，ActiveRecord和类似内容，但是我很难理解一些关系和基础知识。例如：

Being new to Rails, I am having a difficult time finding a website or reference that gives a run down summary of Ruby on Rails. I understand MVC, ActiveRecord, and that sort of stuff on a basic level, but I am having a hard time understanding some of the relationships and fundamentals. For instance:

1. 我需要知道的所有命名约定是什么？


2. 应该如何控制器动作的结构和名称？


3. 在视图中呈现信息的最佳方法是什么（通过：content_for 或 render 部分），什么是我不应该使用的方法？


4. 应该向助手中添加什么，不应该进入什么？


5. 常见的陷阱是什么，或者从一开始我就需要正确地做些什么？


6. 如何模块化代码？那是 lib 文件夹的目的吗？

1. What are all naming conventions I need to be aware of?
2. How should controller actions be structured and named?
3. What are the best ways to render information in a view (via :content_for or render a partial) and what are ways I shouldn't use?
4. What should go into a helper and what shouldn't?
5. What are common pitfalls or something I need to do correctly from the very beginning?
6. How can you modularize code? Is that what the lib folder is for?

我读过一个数字关于这个问题的关于StackOverflow的回答，但是所有这些都只指向我需要阅读的300多页的书，而我只想简要了解重要内容。

I have read a number of responses on StackOverflow in regards to this question, but all of them just point to a 300+ page book I need to read, whereas I just want a concise summary of what's important.

我已经知道一些资源，但是没有为新用户提供基本概念的简要摘要：

Some resources I am already aware of, but do not offer a concise summary of fundamental concepts for new users:

• http://railscasts.com/ （很好，但分散了）


• http://guides.rubyonrails.org/ （假设您已经了解了人际关系


• http://ruby.railstutorial.org/ （按颜色绘制，没有好的摘要）


• 启用AntiPatterns （太好了，但是您必须先读懂整个内容）


• The Rails 3 Way （很棒，但同样，您必须先阅读全文e您了解任何内容）

• http://railscasts.com/ (good, but fragmented)
• http://guides.rubyonrails.org/ (assumes you already understand relationships between everything)
• http://ruby.railstutorial.org/ (paint by colors, no good summary)
• Rails AntiPatterns (great, but you have to read the whole thing before you understand anything)
• The Rails 3 Way (great, but again, you have to read the whole thing before you understand anything)

感谢您提供的任何帮助，参考或指导！

Thank you for any help, references, or guidance you can provide!

PS我希望此Wiki成为现成的文档，因此请根据需要添加，编辑等。

推荐答案

1。我需要了解的所有命名约定是什么？

db表是复数形式，模型是单数形式，控制器是复数形式。因此您拥有 User 模型，该模型由 users 表支持，并且可以通过看到UsersController 。

db table is plural, model is singular, controller is plural. so you have the User model that is backed by the users table, and visible through the UsersController.

文件应命名为该类名称的wide_cased版本。因此 FooBar 类需要放在名为 foo_bar.rb 的文件中。如果使用模块命名空间，则名称空间需要用文件夹表示。因此，如果我们谈论的是 Foo :: Bar 类，则该类应位于 foo / bar.rb 中。

files should be named as the wide_cased version of the class name. so the FooBar class needs to be in a file called foo_bar.rb. If you are namespacing with modules, the namespaces need to be represented by folders. so if we are talking about Foo::Bar class, it should be in foo/bar.rb.

2。控制器动作应该如何组织和命名？

控制器动作应该是RESTful的。这意味着您应该将控制器视为公开资源，而不仅仅是启用RPC。 Rails具有成员操作与资源收集操作的概念。成员动作是在特定实例上运行的内容，例如 / users / 1 / edit 是用户的edit成员动作。收集操作是对所有资源进行操作的操作。因此 / users / search？name = foo 是一个收集操作。

controller actions should be RESTful. That means that you should think of your controllers as exposing a resource, not as just enabling RPCs. Rails has a concept of member actions vs collection actions for resources. A member action is something that operates on a specific instance, for example /users/1/edit would be an edit member action for users. A collection action is something that operates on all the resources. So /users/search?name=foo would be a collection action.

上面的教程描述了如何在路由文件中实际实现这些想法。

The tutorials above describe how to actually implement these ideas in your routes file.

3。在视图中呈现信息的最佳方法是什么（通过：content_for 或呈现局部视图），什么是我不应该使用的方法？

3. What are the best ways to render information in a view (via :content_for or render a partial) and what are ways I shouldn't use?

content_for 应该在您希望将html从内部模板追加到外部模板时使用-例如，能够将视图模板中的某些内容附加到布局模板中。一个很好的例子是添加页面特定的javascript。

content_for should be used when you want to be able to append html from an inner template to an outer template -- for example, being able to append something from your view template into your layout template. A good example would be to add a page specific javascript.

# app/views/layout/application.rb
<html>
  <head>
    <%= yield :head %>
...

# app/views/foobars/index.html.erb

<% content_for :head do %>
  <script type='text/javascript'>
    alert('zomg content_for!');
  </script>
<% end %>

部分用于拆分大文件，或用于多次渲染相同的信息。例如，

partials are either for breaking up large files, or for rendering the same bit of information multiple times. For example

<table>
  <%= render :partial => 'foo_row', :collection => @foobars %>
</table>

# _foo_row.html.erb

<tr>
 <td>
  <%= foobar.name %>
 </td>
</tr>

4。帮手应该做什么，不应该做什么？

您的模板中应该只包含 basic 分支逻辑。如果您需要做更多更激烈的事情，它应该在帮手中。视图中的局部变量是对世界上所有美好事物的憎恶，因此这是您应该成为帮助者的一个好兆头。

your templates should only have basic branching logic in them. If you need to do anything more intense, it should be in a helper. local variables in views are an abomination against all that is good and right in the world, so that is a great sign that you should make a helper.

另一个原因是纯代码重用。如果您一次又一次地做同样的事情，将其拉进一个助手中（如果完全相同，那应该是局部的）。

Another reason is just pure code reuse. If you are doing the same thing with only slight variation over and over again, pull it into a helper (if it is the exact same thing, it should be in a partial).

5。常见的陷阱是什么，或者从一开始我就需要正确地做些什么？

部分对象应该从不直接引用实例（ @）变量，因为它将防止在下一行重复使用。始终通过：locals =>传递数据{：var_name => value} 渲染函数的参数。

partials should never refer directly to instance (@) variables, since it will prevent re-use down the line. always pass data in via the :locals => { :var_name => value } param to the render function.

使视图中的逻辑与渲染视图没有直接关系。如果您可以选择在视图中执行某项操作，然后再执行其他操作，那么在其他地方执行操作的10次操作中有9次是更好的选择。

Keep logic out of your views that is not directly related to rendering your views. If you have the option to do something in the view, and do it somewhere else, 9 times out of 10 doing it somewhere else is the better option.

Rails的口头禅是胖模型，瘦控制器。原因之一是模型是面向对象的，而控制器是固有的过程。另一个是模型可以跨控制器，但是控制器不能跨模型。第三是模型更具可测试性。

We have a mantra in rails that is "fat models, skinny controllers". One reason is that models are object oriented, controllers are inherantly procedural. Another is that models can cross controllers, but controllers cant cross models. A third is that models are more testable. Its just a good idea.

6。您如何模块化代码？这是lib文件夹的目的吗？

lib文件夹用于跨越模型问题的代码（例如，不是模型的东西，但将被多个模型使用）。当您需要在其中放置某些内容时，您将知道，因为您将无法弄清楚将其放入哪种模型。在这种情况下，您可以忽略lib。

the lib folder is for code that crosses the concerns of models (i.e. something that isn't a model, but will be used by multiple models). When you need to put something in there, you will know, because you wont be able to figure out what model to put it in. Until that happens, you can just ignore lib.

要记住的一点是，从Rails 3开始，lib不在自动加载路径上，这意味着您需要要求放在其中的任何内容（或添加

Something to keep in mind is that as of rails 3, lib is not on the autoload path, meaning that you need to require anything you put in there (or add it back in)

自动要求 lib 目录中的所有模块的一种方式：

A way to automatically require all modules in the lib directory:

#config/initializers/requires.rb
Dir[File.join(Rails.root, 'lib', '*.rb')].each do |f|
  require f
end

这篇关于Ruby on Rails基本概念摘要的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！