Удобное использование MVC в Rails

У меня есть контроллер статей, который в данный момент управляет всеми отношениями статей, такими как авторы, переводы, связанные статьи и т. д., в одном действии обновления.

Страница содержит кучу «Списков» с возможностями поиска и сортировки, действиями CRD, формами для создания новых и управления существующими записями ассоциации.

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

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

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

/articles/1/edit/authors

И как должен называться этот контроллер? Должен ли он быть дочерним элементом ArticleController, PeopleController или ApplicationController?

а может все нормально и я параноик?)

UPD

Все условия MVC строго соблюдаются. Вопрос:

Хорошо ли управлять всеми отношениями в одном контроллере. Не только добавлять/удалять отношения, иногда создавать новые, например @article.authors.find_or_create_by_name(name). Отношения в представлении — это не просто теги select! Это полнофункциональные таблицы с собственными возможностями поиска, сортировки и разбиения на страницы.

Если кто-то меня не понимает, давайте спросим по-другому:

как создать «субконтроллер»: если у нас есть ArticleController и его действие редактирования. ArticleController должен управлять только полями в модели статьи. И куча субконтроллеров должна управлять отношениями.

Зачем мне это нужно? Давайте добавим AJAX на такую ​​страницу: никаких серьезных проблем не возникает, но при каждом AJAX-вызове ArticleController.update/edit действия вызывают запрос, и это может выполнять какую-то ненужную работу, например построение отношений Arel для моделей, которые никогда не будут использоваться. Мне нравится делить работу на маленькие независимые части, а не строить один огромный Контроллер, который может все.


ruby-on-rails crud model-view-controller
person Alexander Paramonov    schedule 05.02.2011    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Вы, статья controller, не должны управлять отношениями. Это должно быть в вашем model. Посмотрите активную запись callbacks. Вы можете делать все, что связано с управлением вашими авторами, переводами и т. д. в обратном вызове. Например, в after_update обратном вызове

Вы также хотите использовать nested resources. Например, ваши authors вложены в ваши articles.

person Songo    schedule 06.02.2011
comment
конечно отношения добавление/удаление есть в модели. В контроллере я просто делаю @related_articles = @article.related_articles или @article.related_articles ‹‹ article или @article.related_articles.delete(article) и т. д. - person Alexander Paramonov; 06.02.2011
comment
вложенные ресурсы действительно полезны - person Alexander Paramonov; 06.02.2011

arrow_upward
1
arrow_downward

Может быть, вы можете, например, иметь контроллер авторства, который будет управлять отношениями автор ‹-> статья. Не забывайте, что вы можете использовать модель «объединения» для обработки связи между двумя участвующими моделями. У вас могут быть такие маршруты, как

edit_article_authorships GET /articles/:article_id/authorships/edit(.:format) {:controller=>"authorships", :action=>"edit"}
person Robin    schedule 06.02.2011
comment
спасибо, я думаю, что Authorship может обрабатывать отношения автора ‹-› some_model на основе входных параметров (article_id, post_id и т. д.), я попробую. - person Alexander Paramonov; 06.02.2011