Резюме фундаментальных понятий Ruby on Rails

Будучи новым для Rails, мне сложно найти веб-сайт или ссылку, которая дает краткое резюме Ruby on Rails. Я понимаю MVC, ActiveRecord и подобные вещи на базовом уровне, но мне сложно понять некоторые из отношений и основ. Например:

Каковы все соглашения об именах, о которых мне нужно знать?
Как следует структурировать и назвать действия контроллера?
Каковы наилучшие способы визуализации информации в представлении (через :content_for или render частичный) и какие способы я не должен использовать?
Что нужно делать в помощнике, а что нет?
Каковы распространенные ловушки или что-то, что мне нужно сделать правильно с самого начала?
Как вы можете модулировать код? Это то, что для папки lib для?

Я прочитал несколько ответов на StackOverflow по этому вопросу, но все они просто указывают на более чем 300-страничную книгу, которую мне нужно прочитать, тогда как я просто хочу дать краткий обзор того, что важно.

Некоторые ресурсы, о которых я уже знаю, но не предлагаю краткий обзор основных понятий для новых пользователей:

http://railscasts.com/ (хороший, но фрагментированный)
http://guides.rubyonrails.org/ (предполагается, что вы уже понимаете отношения между всеми)
http://ruby.railstutorial.org/ (краска по цветам, отсутствие хорошего резюме)
Rails AntiPatterns (отлично, но вы должны прочитать все, прежде чем что-либо понимать)
The Rails 3 Way (отлично, но опять же, вам нужно все это прочитать, прежде чем что-либо понимать)

Спасибо за любую помощь, рекомендации или рекомендации, которые вы можете предоставить!

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. Каковы все соглашения об именах, о которых я должен знать?

Таблица db - множественное число, модель единственная, контроллер - множественное число. поэтому у вас есть модель User, которая поддерживается таблицей users и видна через UsersController.

файлы должны быть названы как расширенная версия имени класса. поэтому класс FooBar должен находиться в файле с именем foo_bar.rb. Если вы используете пространство имен с модулями, пространства имен должны быть представлены папками. поэтому, если речь идет о классе Foo::Bar, он должен быть в foo/bar.rb.

2. Как структурировать именовать действия контроллера?

Действия контроллера должны быть RESTful. Это означает, что вы должны думать о своих контроллерах как об экспорте ресурса, а не о том, как просто разрешать RPC. Rails имеет концепцию действий членов и действий коллекций для ресурсов. Действие элемента - это то, что работает на конкретном экземпляре, например /users/1/edit будет действительным элементом редактирования для пользователей. Действие коллекции - это то, что работает на всех ресурсах. Таким образом, /users/search?name=foo будет действием коллекции.

В приведенных выше учебниках описано, как реально реализовать эти идеи в файле маршрутов.

3. Каковы наилучшие способы визуализации информации в представлении (через :content_for или частичный) и какие способы я не должен использовать?

content_for следует использовать, когда вы хотите добавить html из внутреннего шаблона в внешний шаблон - например, возможность добавить что-то из вашего шаблона в шаблон макета. Хорошим примером может быть добавление 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 %>

частичные файлы предназначены либо для разбивки больших файлов, либо для повторного отображения одного и того же бита информации. Например

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

# _foo_row.html.erb

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

4.Что должно идти в помощник, а что нет?

ваши шаблоны должны иметь только базовую логику ветвления. Если вам нужно сделать что-нибудь более интенсивное, оно должно быть в помощнике. локальные переменные во взглядах являются мерзостью против всего, что хорошо и правильно в мире, так что это отличный признак того, что вы должны стать помощником.

Другая причина - просто повторное использование кода. Если вы делаете то же самое с небольшими вариациями снова и снова, потяните его в помощника (если это то же самое, оно должно быть в частичном).

5. Каковы общие ловушки или что-то, что мне нужно сделать правильно с самого начала?

Частичные части не должны ссылаться непосредственно на переменные instance (@), так как это предотвратит повторное использование строки. всегда передавайте данные через параметр :locals => { :var_name => value } в функцию рендеринга.

Сохраняйте логику из своих представлений, которая напрямую не связана с рендерингом ваших представлений. Если у вас есть возможность сделать что-то в этом представлении и сделать это где-то еще, то 9 раз из 10, сделав это где-то в другом месте, это лучший вариант.

У нас есть мантра в рельсах, которая представляет собой "толстые модели, тощие контроллеры". Одна из причин заключается в том, что модели ориентированы на объекты, контроллеры являются процедурными. Другим является то, что модели могут пересекать контроллеры, но контроллеры не имеют перекрестных моделей. В-третьих, модели более проверяемы. Это просто хорошая идея.

6. Как вы можете модулировать код? Для чего предназначена папка lib?

папка lib предназначена для кода, который пересекает проблемы моделей (т.е. что-то, что не является моделью, но будет использоваться несколькими моделями). Когда вам нужно что-то там положить, вы узнаете, потому что вы не сможете определить, какую модель вставить. Пока это не произойдет, вы можете просто игнорировать lib.

Что-то, о чем нужно помнить, так это то, что с rails 3 lib не находится на пути автозагрузки, а это значит, что вам нужно require все, что вы там вложили (или добавить его обратно)

Способ автоматического запроса всех модулей в каталоге lib:

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

Ответ 2

Я написал несколько соглашений об именах некоторое время назад:

Соглашения о рельсах

Общие

Все имена файлов находятся в snake_case по тем же соглашениям - Модель: сингулярный (например, Restaurant) - Контроллер: множественное число (например, RestaurantsController) - Таблица в БД: множественное число (например, restaurants) - URL-адреса: все в множественном числе (например, /restaurants, /restaurants/:id, /restaurants/new)

`rails generate` Команды

Создать модель: сингулярный (потому что имя модели сингулярно). например rails g model Restaurant name:string rating:integer
Создать перенос: множественное число (потому что мы используем имя таблицы). например rails g migration AddDescriptionTo restaurants description:text
Создать контроллер: множественное число, например. rails g controller restaurants index show

Модель (единственная)

`ActiveRecord` методы

Все в единственном числе, потому что все методы ActiveRecord связаны с моделью. Примеры: - Restaurant.all - Restaurant.create(name: "Burger King", rating: 2) - Restaurant.find(params[:id])

Ассоциации

Singular в belongs_to. Поскольку он принадлежит элементу один.
Множественное в has_many. Поскольку у него есть много элементов.

например. `` `Рубин класс Ресторан & ActiveRecord:: Base has_many: отзывы конец

class Review < ActiveRecord:: Base принадлежит: ресторану конец `` `

Маршруты

Ресурсы

Множественное при определении маршрута для ресурса:

ruby resources :restaurants

Помощники маршрута

index: множественное число (потому что мы показываем список элементов). например restaurants_path. Может также использоваться для create.
show: единственное (мы показываем только один элемент, ему нужен элемент внутри скобок). например restaurant_path(@restaurant). Также может использоваться для update и delete.
new: единственное. например new_restaurant_path