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關聯）和內聯表單來創建新的對象和關聯的MyListItem。這些內聯操作在很大程度上依賴於partials和RJS。

現在我有兩個選擇：

• 我能控制的方法例如方便，在這兩個MyItemController和MyListController，其中每個負責其相關的視圖創建一個新的MyItem。這略微違反了DRY原則，但它簡化了渲染/重定向邏輯以及部分/ RJS與控制器操作的關聯。

• 或者我可以將表格和AJAX鏈接從MyList視圖提交到MyItemController，然後在適當時必須小心地從MyList中提取部分或RJS。這似乎還要求我在MyList相關視圖中爲每個link_to_remote指定一個：controller => my_list。這似乎是一種更加REST風格的方法，並且限制了將一個控制器創建爲MyItem對象，但它在某種程度上使控制器邏輯複雜化。

你更喜歡哪種方法？爲什麼？

Answer 1

我經常和我自己也有這個爭論，我想我通常會喜歡選項＃1。作爲最佳實踐，我們通常會爭取瘦身控制器，並尋找將初始化/創建邏輯分解到模型中的方法。在一個完美的世界裏，動作中邏輯的大部分將會是你在選項＃2上分支的視圖特定的渲染/重定向邏輯。

我也覺得不同意見的要求往往會隨着時間推移出現分歧：「我們希望在此頁面上顯示不同的Flash消息」。對於選項＃2，這只是更多的分支。

將任何對模型合理的初始化邏輯進行因子分解並且可能在控制器中使用普通的before_filter之後，選項＃1可能會覺得乾淨& DRY。

Answer 2

這裏我最初的傾向是你的第一個建議選項，但是有一個lib模塊（這兩個控制器都包含）來幹掉任何重複的代碼或圍繞MyItems的邏輯（當然，儘可能多的應該通過DRYed up首先是MyItem模型）。這使代碼既簡單又可維護。當你處理這樣複雜的AJAX設置時，代碼邏輯簡單的好處超過了嚴格RESTful方法的好處。