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。

现在我有两个选择：

我可以使用控制器方法来促进例如在MyItem和MyItemController中创建新的MyListController，其中每个都负责其关联的视图。这略微违反了DRY原则，但它简化了渲染/重定向逻辑以及部分/ RJS与控制器操作的关联。
或者我可以将MyList视图中的表单和AJAX链接提交给MyItemController，然后必须在适当的时候注意从MyList呈现部分或RJS。这似乎也要求我指定一个：controller =＆gt; MyList个相关视图中每个link_to_remote的my_list。这似乎是一种更RESTful的方法，并且限制了MyItem对象到一个控制器的创建，但它在一定程度上使控制器逻辑复杂化。

您更喜欢哪种方法？为什么？

Answer 1

我经常与自己进行辩论，我认为我通常喜欢选项＃1。作为一种最佳实践，我们通常会努力寻找瘦的控制器，并寻找将初始化/创建逻辑分解为模型的方法。在一个完美的世界中，动作中逻辑的大部分将是您要为选项＃2分支的视图特定渲染/重定向逻辑。

我也觉得不同观点的要求会随着时间的推移而出现分歧：“我们希望在此页面上显示不同的Flash消息”。这对于选项＃2来说只是更多的分支。

在考虑了对模型合理的任何初始化逻辑并且可能在控制器中使用公共的before_filter之后，选项＃1可能会感觉非常干净＆amp;干。

Answer 2

我最初的倾向是你的第一个建议选项，但是有一个lib模块（两个控制器都包含）来干掉MyItems周围的任何重复代码或逻辑（当然，尽可能多地通过MyItem中的DRYed up）模型第一）。这使代码既简单又易于维护。当您处理这样复杂的AJAX设置时，代码逻辑简单性的好处超过了严格RESTful方法的好处。

Rails RESTful控制器与视图特定控制器

2 个答案: