Как организовать действия, которые не вписываются в обычный MVC

Question

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

Либо я мог оставить все как есть, либо я думал о создании пространства имен опроса и создании как Survey:: TakeController и обзор :: ShareController.Тогда я бы тогда, наверное, использовал новое действие или индекс?

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

Answer 1

Чтобы мыслить RESTful, вам, вероятно, следует перестать думать о них как о «контроллерах с действиями» и начать думать о них как о «объектах, которые можно создавать / обновлять и т. Д.» - контроллеры являются просто прокси для представлений, которые показывают результаты создания / обновление объекта.

В большинстве случаев я обнаружил, что дополнительное действие на самом деле является всего лишь разновидностью «обновления» - только с его собственными особыми требованиями (например, только определенные люди могут обновить его или что-то еще). Такая логика часто может быть внутри самой модели (например, «MyModel # can_be_edited_by? (Some_user)»).

Иногда вы обнаруживаете, что на самом деле у вас есть дополнительная «скрытая» модель, которой нужен собственный интерфейс RESTful.

Например, с вашим "принять" опрос - я предполагаю, что у вас есть что-то вроде "SurveyResult", и человек может "создать" опрос ", но когда он" принимает "опрос, он фактически создает «SurveyResult» (другой комментатор назвал это «SurveyParticipation» - но это то же самое).

Дело в том, что у вас, вероятно, будет несколько SurveyResults, каждый из которых own_to: survey и assign_to: some_user_model.

Тогда вы можете настроить хорошие маршруты отдыха, такие как: / обзоры / 123-my_favourite_colour / Результаты

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

Это на самом деле RESTful способ просмотреть эту часть вашего объектного пространства.

Что касается обмена опросом - это более интересный вопрос. Это зависит от того, как у вас есть настройки авторизации для «обмена». Это также зависит от того, что вы подразумеваете под «поделиться». Разделяете ли вы результаты опроса или сами опрашиваете объект опроса (чтобы другой пользователь мог редактировать вопросы) или вы (как человек, который только что принял участие в опросе) делитесь ссылкой на опрос, чтобы ваш друзья тоже могут пройти опрос?

Для первых двух выше - я бы рассмотрел класс "SurveyPermission", который принадлежит_для: опросом и принадлежат_для: some_user_model. Вы можете создать SurveyPermission для другого пользователя - и опросы могут быть отредактированы создателем или кем-либо, у кого есть разрешение на его редактирование. Таким образом, действие общего доступа заключается в создании SurveyPermission. Хотя, честно говоря, ваш SurveyPermission, скорее всего, будет использоваться только для создания и удаления, поэтому может быть проще вставить эти два действия в контроллер Survey.

Для последнего - ну, это просто отправка кому-нибудь ссылки "create_survey_result (@survey)" ...

Обновление:

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

В этом случае - единственное возникающее пространство имен находится в маршрутизации:

map.resources :surveys do |s|
  s.resources :results
  s.resources :shares # ???
end

дает такие маршруты как:

new_survey_path
surveys_path
new_survey_result_path(@survey)
survey_results_path(@survey)

Answer 2

Если вы хотите остаться с подходом RESTful, то у вас может быть ресурс SurveyParticipation, с действиями new / create, которые вызываются, когда кто-то берет опрос.И, хм, SurveyShare ресурс для обмена опросами.Хотя это имя довольно неловко!

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