php mvc架構中的控制器總感覺就是萬能類.

在控制器中編寫頁面邏輯的時候，調度model邏輯的時候，因為一個控制器往往針對一個頁面. 雖然控制器往往也是遵循class寫法,但是感覺控制器寫出來就是一個萬能類.因為一個頁面的功能資料多種多樣,例如有商品資料,有使用者資料等等. 可能都需要通過這個方法輸出出來. 但是這就違背了 oop單一職責. 怎麼解決這個問題呢?

回複內容：

在控制器中編寫頁面邏輯的時候，調度model邏輯的時候，因為一個控制器往往針對一個頁面. 雖然控制器往往也是遵循class寫法,但是感覺控制器寫出來就是一個萬能類.因為一個頁面的功能資料多種多樣,例如有商品資料,有使用者資料等等. 可能都需要通過這個方法輸出出來. 但是這就違背了 oop單一職責. 怎麼解決這個問題呢?

這是個好問題。

程式都是根據商務邏輯而產生的。事實上如果你的頁面要求多種資料彙集（注），那麼你的程式就必然在某個單點出現多種資料的彙集。這是程式在商務邏輯約束之下產生的本徵特點，用任何技術都是不可能消滅的。

在一個典型的MVC結構中，一般在C層彙集資料。所以一個C對接了一大堆的資料才是正常的。無需自創“超級類”這樣憑空讓我們感到擔憂的名詞。

實際上單一職責原則的重點在於“單一職責”，而不是“單一對接者”。對於Web架構的C，一般的職責只有：

1. 從M擷取資料

2. 簡單合并資料提供給V

3. 和HTTP等網路通訊協定完成對接

所以“從多個M擷取資料”這種情況，肯定是沒有問題的。對接者多？只要對接做的事情是同一種，那就是單一責任。

但如果混入了任何以下的代碼，那麼C的單一職責就很可能出現了問題：

• 資料擷取的具體方法，例如資料庫讀寫（這是M的責任）

• 對擷取的資料進行加工處理（這是M的責任）

• 將A模型擷取來的資料傳遞給B模型（這是Service的責任）

• 組織並實現一個有若干個步驟的商務程序（這是Service的責任）

注1：例如商城的商品列表，一般有頁首的基本資料、頁面本文的商品資訊、側邊欄的商品類別資訊，以及貫穿頁面各處的廣告推廣資訊等。

分層啊，加上一層，所有實質性操作都放在這一層，然後控制器調用

參考一下這個 是不是更有思路http://baike.baidu.com/link?url=DnVleYsISmUvUoyqcaupBzU7Zhk1mq3FPUM7ji55cp8xqBarGuSCI7vjdJk_vCj8rUYYqICUKt2SGKQ0GjJKRHExnXvydaHRn8tGQIKXPW7

