ruby-on-rails - Rails RESTful Controller 与 View 特定 Controller

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 模型不仅仅是一个简单的连接表，它还有其他属性。

应用程序中有两个主要 View 。一个显示所有 MyItems，无论它属于哪个 MyList，并为这些提供标准的 CRUD 操作。另一个 View 显示一个 MyList，其中包含来自其所有 MyListItems 和每个相关联的 MyItem 的数据。此 View 允许对现有的 MyItem 对象(通过 MyListItem 与列表相关联)进行内联编辑，并允许内联表单创建新的 MyItem 对象和关联的 MyListItem。这些内联操作在很大程度上依赖于 partials 和 RJS。

现在我有两个选择:

• 我可以使用 Controller 方法来促进，例如，在 MyItemController 和 MyListController 中创建一个新的 MyItem，其中每个对其相关观点负责。这稍微违反了 DRY 原则，但它简化了渲染/重定向逻辑以及 partials/RJS 与 Controller 操作的关联。

• 或者我可以将来自 MyList View 的表单和 AJAX 链接提交给 MyItemController，然后它必须注意从 呈现部分或 RJS >MyList 在适当的时候。这似乎还要求我为 MyList 相关 View 中的每个 link_to_remote 指定一个 :controller => my_list。这似乎是一种更 RESTful 的方法，并将 MyItem 对象的创建限制在一个 Controller 中，但它使 Controller 逻辑有些复杂。

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

Answer 1

我也经常和自己争论，我想我通常赞成选项 #1。作为最佳实践，我们通常致力于瘦身 Controller 并寻找将初始化/创建逻辑分解到模型中的方法。在一个完美的世界中，大多数 操作中的逻辑将是 View 特定的呈现/重定向逻辑，您将为选项 #2 分支。

我还觉得随着时间的推移，不同观点的要求往往会有所不同:“我们想在此页面上显示不同的即时消息”。对于选项 #2，这只是更多的分支。

在考虑了对模型合理的任何初始化逻辑并且可能在 Controller 中使用了一个通用的 before_filter 之后，选项 #1 可能会感觉非常干净和干燥。