Сингулярные или множественные имена контроллеров и помощников в Rails

Ответ 1

Определенно множественное число.

С спокойной маршрутизацией и сингулярным контроллером

контроллер:

dog_controller.rb  

Маршруты:

map.resources :dogs  # => blows up  
map.resources :dog  # is ok, but...  
dogs_path # => blows up  
dog_path  # => ok  

Использование контроллера множественного числа

контроллер:

dogs_controller.rb

Маршруты:

map.resources :dogs  
dogs_path # => ok  
dog_path # => ok  

rails generate controller --help имеет множество примеров:

Example:
'rails generate controller CreditCards open debit credit close'

CreditCards controller with URLs like /credit_cards/debit.
    Controller: app/controllers/credit_cards_controller.rb
    Test:       test/controllers/credit_cards_controller_test.rb
    Views:      app/views/credit_cards/debit.html.erb [...]
    Helper:     app/helpers/credit_cards_helper.rb

Ответ 2

Использование множественных имен для контроллеров - это просто соглашение.

Многословные имена обычно более естественны (особенно для контроллеров, привязанных непосредственно к определенной модели: User → Users и т.д.), но вы можете использовать все, что хотите.

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

Ответ 3

Модель является сингулярной, поскольку она ссылается на один объект, такой как Пользователь. Контроллер множественный, потому что это элементы управления (методы) для коллекции пользователей. Как называют все маршруты для этого отдельного разработчика. Я никогда не жаловался, что URL-адрес веб-запроса является единственным или множественным. Конечным результатом является поддержание общего соглашения для текущих и будущих участников при показе качественных страниц или запросов API для конечных пользователей.

Ответ 4

У вас есть очень полное объяснение в руководствах Rails: http://edgeguides.rubyonrails.org/routing.html#resource-routing-the-rails-default

Ответ 5

Это соглашение Rails, что один контроллер обрабатывает одну модель, может ли один или несколько экземпляров этой модели существовать во время выполнения. Однако у вас может быть приложение Rails, в котором (некоторые из) контроллеров (и связанных с ним представлений) не связаны с какой-либо конкретной моделью, а скорее обрабатывают более сложный набор функций. В этом случае автоматическая плюрализация не имеет никакого смысла.

Приложение Rails, в котором я сейчас работаю, вписывается в эту категорию, и это просто раздражение для меня, что Rails ожидает, что идентификаторы, которые я определяю как единственное в одном месте, затем используются в их множественных формах в других местах. Например, я мог бы определить что-то вроде этого в config/routes.rb:

  resource :dashboard, :only => [:show]

а затем я хочу, чтобы контроллер DashboardController отображал сводную информацию о некоторых аспектах приложения, собирая информацию из более чем одной таблицы базы данных. Итак, здесь Dashboard не относится к какой-либо модели приложения, и было бы просто странно иметь имя контроллера DashboardsController.

Я нашел хорошее решение для раздражения автоматической плюрализации в этом ответе. Короче говоря, отредактируйте файл config/initializers/inflections.rb и добавьте слова, которые вы не хотите автоматически использовать для этого определения:

ActiveSupport::Inflector.inflections do |inflect|
  inflect.uncountable %w( dashboard foo bar baz )
end

Ответ 6

Мне становится лучше, когда я использую единственное значение для имени контроллера

Ответ 7

Если контроллер является ресурсом, то он должен быть множественным...

Например

Контроллер

articles_controller.rb

Model

article.rb

Но вы можете использовать уникальные имена контроллеров, если у вас нет соответствующих моделей, таких как

welcome_controller.rb

Ответ 8

Соглашение об именах контроллеров в Rails способствует плюрализации последнего слова в имени контроллера, хотя строго не требуется (например, ApplicationController).

Например, ClientsController предпочтительнее ClientController, SiteAdminsController предпочтительнее SiteAdminControlle r или SitesAdminsController и т.д.

Следуя этому соглашению, вы сможете использовать генераторы маршрутов по умолчанию (например, ресурсы и т.д.), не требуя квалификации каждого :path или :controller, и будет поддерживать согласование URL-адресов и путей в вашем приложении.

Ссылка: Дополнение к правилам именования контроллеров Docs

Ответ 9

Использование множественных чисел просто звучит лучше, а затем, если у вас есть контроллер, который обрабатывает особый ресурс, то есть пользователь, то вы все равно можете указать URL-адрес/пользователя.

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