Summary of Ruby on Rails fundamental concepts

2019-03-07 13:37发布

站内文章 / 前端开发
41 0 0

问题:

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. 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?

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/ (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!

P.S. I would like this wiki to become a living document, so please add to it, edit it, etc. as you feel necessary.

回答1:

1. What are all naming conventions I need to be aware of?

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.

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. How should controller actions be structured and named?

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. 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 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.What should go into a helper and what shouldn't?

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. What are common pitfalls or something I need to do correctly from the very beginning?

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.

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.

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. How can you modularize code? Is that what the lib folder is for?

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.

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)

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


回答2:

I wrote some naming conventions some time ago:

Rails conventions

General

All filenames are in snake_case following the same conventions - Model: singular (e.g. Restaurant) - Controller: plural (e.g. RestaurantsController) - Table in DB: plural (e.g. restaurants) - URL's: all in plural (e.g. /restaurants, /restaurants/:id, /restaurants/new)

rails generate Commands

  • Create model: singular (because the name of the model is singular). e.g. rails g model Restaurant name:string rating:integer
  • Create migration: plural (because we use the name of the table). e.g. rails g migration AddDescriptionToRestaurants description:text
  • Create controller: plural e.g. rails g controller Restaurants index show

Model (singular)

ActiveRecord methods

All in singular, because all ActiveRecord's methods are linked to the model. Examples: - Restaurant.all - Restaurant.create(name: "Burger King", rating: 2) - Restaurant.find(params[:id])

Associations

  • Singular in the belongs_to. Because it belongs to one element.
  • Plural in the has_many. Because it has many elements.

e.g.

class Restaurant < ActiveRecord::Base
  has_many :reviews
end

class Review < ActiveRecord::Base
  belongs_to :restaurant
end

Routes

Resources

Plural when defining a route for a resource:

resources :restaurants

Route helpers

  • index: plural (because we are showing a list of elements). e.g. restaurants_path. Can also be used used for create.
  • show: singular (we are showing just one element, it needs the element inside parenthesis). e.g. restaurant_path(@restaurant). Can also be used for update & delete.
  • new: singular. e.g. new_restaurant_path


标签： ruby-on-rails reference conventions summary
举报

收藏的人(0)

Ta的文章 更多文章
登录 后发表评论
0条评论
还没有人评论过~