Rails RESTful控制器与查看特定控制器

这个设计问题需要一些背景知识，所以请耐心等待。Rails RESTful控制器与查看特定控制器

我目前有三种型号都走这样的：

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关联）和内联表单来创建新的对象和关联的MyListItem。这些内联操作在很大程度上依赖于partials和RJS。

现在我有两个选择：

我能控制的方法例如方便，在这两个MyItemController和MyListController，其中每个负责其相关的视图创建一个新的MyItem。这略微违反了DRY原则，但它简化了渲染/重定向逻辑以及部分/ RJS与控制器操作的关联。
或者我可以将表格和AJAX链接从MyList视图提交到MyItemController，然后在适当时必须小心地从MyList中提取部分或RJS。这似乎还要求我在MyList相关视图中为每个link_to_remote指定一个：controller => my_list。这似乎是一种更加REST风格的方法，并且限制了将一个控制器创建为MyItem对象，但它在某种程度上使控制器逻辑复杂化。

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

来源

2010-09-28 Einar

我经常和我自己也有这个争论，我想我通常会喜欢选项＃1。作为最佳实践，我们通常会争取瘦身控制器，并寻找将初始化/创建逻辑分解到模型中的方法。在一个完美的世界里，动作中逻辑的大部分将会是你在选项＃2上分支的视图特定的渲染/重定向逻辑。

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

将任何对模型合理的初始化逻辑进行因子分解并且可能在控制器中使用普通的before_filter之后，选项＃1可能会觉得干净& DRY。

来源

2010-10-22 18:26:21 njorden

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

来源

2010-10-19 21:01:05

Rails RESTful控制器与查看特定控制器

回答

相关问题