Zend_Framework-在哪裏放置$ _GET和$ _POST（HTTP請求）處理？

Question

我最近閱讀this post，這導致了一系列其他帖子似乎都提出了相同的想法：模型完成所有工作，視圖應該能夠直接與模型進行通信，反之亦然，而控制器保持不變。然而，所示的所有示例都相當簡單，沒有一個真正顯示任何人試圖實現對請求/響應週期的全面處理的例子，這讓我想知道「模型是否應該負責處理請求（即$ _GET，$ _POST等）本身？「和「控制器是否應該作爲傳遞來實例化必要的模型並將模型傳遞給視圖？」。 （事實上​​，我發現一個例子採取了在模型中嵌入Zend_Form對象的極端）

從我閱讀福勒關於MVC和控制器的一般看來，乍一看，控制器層越薄越好。但後來我花時間回顧並研究了他對MVC和Front Controller的看法（因爲兩種模式都定義了控制器，所以它們只是混淆了水域），現在我的直覺表明Zend_Framework在實現這兩種模式的過程中實際上創建了一個在MVC中執行Controller的功能的複合對象，以及在Front Controller（或其他）中執行Command對象的複合對象。

所以我想知道其他人在應用程序中實現了類似模式的一般意見是什麼 - 您是在控制器層完全處理請求還是讓模型知道請求並直接處理參數在模型中？

Answer 1

我的第一個想法是避免處理模型中的任何請求。這是控制器的工作。這是爲什麼：假設你有一個處理你的請求的模型（GET或POST）。這個結構很可能在初期運作良好。現在，假設您想添加某種AJAX功能或爲您的系統提供服務接口。現在您接受的不僅僅是簡單的GET/POST，即JSON或XML，您的模型將不得不區分每種請求類型並知道如何解析它們。我相信破壞了模型代碼的很多簡單和清晰。我同意控制器層應該很薄，但它也應該有一個角色和一個專業知識。對我來說，一個控制器的專長是：

1. 處理傳入的請求
2. 交付數據模型
3. 請求/從模式
4. 接受數據傳遞數據的模型視圖

我對這個模型的視圖應該知道多少有些猶豫。有人建議模型直接進入視圖，但我認爲這是脆弱的耦合。它經常導致視圖中的邏輯。另外，如果您正在開發一個項目，那些從事視圖工作的團隊成員不像主要開發人員那樣精通編程，那麼他們會爲了跟上變化而承擔很大的負擔。我傾向於將我交給我的觀點的數據打包成中性結構，而不是交出完整的模型。

我對MVC的解釋大多是務實的。該模型的工作是模型您正在處理的域名，而不應該關心數據來自何處。我經常構建模型代碼，假設它可能在命令行應用程序或桌面應用程序中的Web應用程序之外使用。這種聯合很少發生，但它導致了每一層的明確目的。控制器的工作是在相關方之間移動數據，無論是客戶請求，模型還是視圖。控制器應該具有非常小的域邏輯，但這並不意味着它沒有任何代碼。最後，該視圖應該看起來很漂亮。希望有所幫助。

Answer 2

處理用戶指令/輸入（如HTTP請求）是控制器的工作。模型用於處理/操作/獲取數據，視圖用於向用戶顯示結果。這意味着視圖和模型之間的連接大多數時候是控制器的職責。