这个设计问题需要一些上下文,所以请耐心等待。
我目前有三个模型是这样的:
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 逻辑有些复杂。
您更喜欢哪种方法,为什么?
最佳答案
我也经常和自己争论,我想我通常赞成选项 #1。作为最佳实践,我们通常致力于瘦身 Controller 并寻找将初始化/创建逻辑分解到模型中的方法。在一个完美的世界中,大多数 操作中的逻辑将是 View 特定的呈现/重定向逻辑,您将为选项 #2 分支。
我还觉得随着时间的推移,不同观点的要求往往会有所不同:“我们想在此页面上显示不同的即时消息”。对于选项 #2,这只是更多的分支。
在考虑了对模型合理的任何初始化逻辑并且可能在 Controller 中使用了一个通用的 before_filter 之后,选项 #1 可能会感觉非常干净和干燥。
关于ruby-on-rails - Rails RESTful Controller 与 View 特定 Controller ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3813690/