Rails RESTful контроллеры против просмотра определенных контроллеров

Question

Этот вопрос о дизайне нуждается в некотором контексте, поэтому, пожалуйста, потерпите меня.

В настоящее время у меня есть три модели, которые выглядят примерно так:

class MyItem < ActiveRecordBase
    has_many :my_list_items
    ...

class MyList < ActiveRecordBase
    has_many :my_list_items
    has_many :my_items, :through => :my_list_items
    ...

 class MyListItem < ActiveRecordBase
     belongs_to :my_item
     belongs_to :my_list
     has_many :my_list_item_properties

 class MyListItemProperty < ActiveRecordBase
     belongs_to :my_list_item

Как видите,Модель MyListItem - это не просто таблица соединений, но и другие свойства.

В приложении есть два основных вида.Один отображает все MyItems независимо от того, к какому MyList он принадлежит, и предоставляет для них стандартные операции CRUD.В другом представлении отображается MyList, с данными всех его MyListItems и связанных MyItem каждого.Это представление позволяет выполнять встроенное редактирование существующих MyItem объектов (которые связаны со списком через MyListItem), а также встроенные формы для создания новых MyItem объектов и связанных MyListItem.Эти встроенные действия в значительной степени зависят от партиалов и RJS.

Теперь у меня есть два варианта:

• У меня могут быть методы контроллера, например, для создания нового * 1024.* в MyItemController и MyListController, где каждый отвечает за свои связанные представления.Это небольшое нарушение принципа DRY, но оно упрощает логику рендеринга / перенаправления и связь partials / RJS с действиями контроллера.

• Или я могу создавать формы и ссылки AJAX изMyList представления передаются в MyItemController, который затем должен позаботиться о рендеринге партиалов или RJS из MyList, когда это необходимо.Это также требует от меня указать: controller => my_list для каждого link_to_remote в MyList связанных представлениях.Это, кажется, более подход RESTful и ограничивает создание MyItem объектов одним контроллером, но это несколько усложняет логику контроллера.

Какой метод вы предпочитаете и почему?

Answer 1

У меня часто бывают эти споры с самим собой, и я думаю, что я обычно предпочитаю вариант # 1. В качестве лучшей практики мы, как правило, стремимся к созданию тонких контроллеров и ищем способы включения логики инициализации / создания в модель. В идеальном мире большинство логики в действии было бы логикой рендеринга / перенаправления для конкретного вида, на которую вы переходили бы для варианта №2.

Я также чувствую, что требования для разных представлений со временем расходятся: «Мы хотели бы показать на этой странице другое флэш-сообщение». Что было бы просто более разветвленным для варианта № 2.

После учета любой логики инициализации, которая является разумной для модели, и, возможно, использования общего before_filter в контроллерах, вариант # 1, вероятно, будет казаться довольно чистым и сухим.

Answer 2

Мой первоначальный уклон был бы вашим первым предложенным вариантом, но с модулем lib (который включает в себя оба контроллера), чтобы высушить любой дублированный код или логику вокруг MyItems (конечно, насколько это возможно, DRYed вверх в MyItem модель первая). Это делает код простым и понятным. Когда вы имеете дело со сложными настройками AJAX, подобными этой, преимущества простоты логики кода перевешивают преимущества строго RESTful-подхода.