Имена контроллеров и помощников в единственном или множественном числе в Rails


112

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


2
У меня была та же дилемма, пытаясь выбрать единственное или множественное число имен контроллеров!
Эндрю

15
спасибо :) У Rails-культуры есть способ заставить вас чувствовать себя глупо, если вы сомневаетесь в подобных вещах.
allyourcode

Ответы:


158

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

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

контроллер:

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

23
согласовано. Сбивает с толку тот факт, что в справочном сообщении генератора Rails 3.1 для контроллеров в качестве примера используется «CreditCard» (единственное число).
bantic

4
Справка Rails теперь использует множественное число: рельсы генерируют контроллер CreditCards открывают дебетовые кредиты закрывают
notapatch

3
здесь все еще есть кредитная
карта

Как мы можем написать локали для сингулярного контроллера stackoverflow.com/questions/29650094/...
Сантош

Так что наименование должно быть во множественном числе и приходиться падежом. например:: rails generate controller Dogs новый индекс создать удалить уничтожить редактировать "??
BKSpurgeon

27

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

Множественные имена обычно звучат более естественно (особенно для контроллеров, которые напрямую привязаны к определенной модели: Пользователь -> Пользователи и т. Д.), Но вы можете использовать все, что захотите.

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


10
Разве не было бы более естественным для контроллера, соответствующего пользователю, быть UserController ?? Кроме того, если вы полагаетесь на маршруты по умолчанию, вы получите URL-адреса, которые выглядят как / users / edit, что похоже на то, что вы редактируете всех пользователей. Для меня это совсем не естественно.
allyourcode

5
@allyourcode: ну, думаю, это все субъективно. для меня наличие / users список всех пользователей более естественно, чем / user.
Кан Берк Гюдер,

1
ох, и это способ RESTful.
Кан Берк Гюдер,

3
@ Может ли "RESTful way" звучит как культовое пение. Это меня не особо удивляет, поскольку Rails в целом довольно религиозен. Мне нравится, что все Rails одержимы REST, но маршруты по умолчанию никуда не годятся. Даже настройка маршрутов RESTful неестественна. Включение: conditions => {: method =>: post} во второй аргумент для подключения не имеет смысла, поскольку хэш должен указывать, как обрабатывать любой запрос, который соответствует текущему правилу, а не то, соответствует ли какой-либо данный запрос текущему правилу .
allyourcode

2
@allyourcode В соответствии с этим маршрутом редактирования по умолчанию является / users /: id / edit вместо / users / edit. Сказать «из всех пользователей, отредактировать пользователя с id: id» звучит для меня совершенно естественно.
DavidG

19

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


12

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


4
на самом деле это правильный ответ b / c, если вы его читаете, он объясняет, что множественное число - правильный ответ для набора ресурсов. Для одноэлементного ресурса единственное число - правильный ответ. Примеры в документации. И на самом деле, об этом хорошо сказано в другом посте: stackoverflow.com/questions/2614858/…
Роб

Ответы, подкрепленные официальными ссылками, такими как в этом посте, очень помогают новичкам! Спасибо
Васиф Хоссейн

9

По соглашению 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

3

Соглашение об именах контроллеров в Rails поддерживает множественное число последнего слова в имени контроллера, хотя это не является строго обязательным (например,ApplicationController ).

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

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

Ссылка: Соглашение об именах контроллеров - документ Rails



2

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

Например

контроллер

articles_controller.rb

Модель

article.rb

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

welcome_controller.rb

1

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

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


Те же комментарии, что и для Джана Берк Гудера. Кроме того, у меня были проблемы с последним предложением / абзацем из-за того, что в нем было так мало знаков препинания!
allyourcode

1
Извините за это, я имел в виду только то, что, возможно, было бы лучше создать собственные помощники, чем использовать значения по умолчанию, поскольку имена стандартных помощников не всегда полностью отражают, где они будут использоваться. Если у вас есть несколько вспомогательных методов, которые будут использоваться для макета, назовите его layout_helper.
nitecoder
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.