MVC：關於數據訪問的視圖和模型交互等

Question

模型應該是數據結構嗎？ MVC中的服務（數據訪問，業務邏輯）在哪裏？

讓我們假設我有一個顯示客戶訂單列表的視圖。我有一個控制器類來處理視圖控件（按鈕等）上的點擊。

控制器應該啓動數據訪問代碼嗎？認爲按鈕點擊，重新加載訂單查詢。還是應該通過模型層？

任何示例代碼都會很棒！

Answer 1

通常我實現的MVC如下：

查看 - 從控制器接收數據並生成輸出。通常只有顯示邏輯應該出現在這裏。例如，如果您想採用現有網站並生成移動版/ iPhone版本，則只需更換視圖即可（假定您需要相同的功能）。

模型 - 包裝模型中的數據訪問。在我的應用程序中，所有SQL都存在於模型層中，在視圖或控制器中不允許直接訪問數據。正如Elie在另一個答案中指出的那樣，這裏的想法是（至少部分）將控制器/視圖與數據庫結構的變化隔離開來。模型也是實現邏輯的好地方，例如每當一個字段改變時更新「最後修改」日期。如果您的應用程序的主要數據源是外部Web服務，請考慮是否將其包含在模型類中。

控制器 - 用於將模型和視圖粘合在一起。在此處實現應用程序邏輯，驗證表單，將數據從模型傳輸到視圖等。

例如，在我的應用程序中，當請求頁面時，控制器將從模型中獲取所需的任何數據，並將其傳遞到視圖以生成用戶看到的頁面。如果該頁面是表單，則可以提交表單，控制器處理驗證，創建必要的模型並使用它來保存數據。

如果您遵循此方法，模型最終會變得非常通用且可重用。您的控制器的大小和複雜程度都是可控的，因爲數據訪問和顯示已分別被移除到模型和視圖中，您的視圖應該足夠簡單，以便設計師（只需少量培訓）就能理解它們。

Answer 2

該視圖會將UI中發生的單擊事件轉發給控制層，該控制層將包含所有業務邏輯，並將依次調用僅進行數據庫調用的模型層。只有模型層應該進行數據庫調用，否則你將打敗MVC設計模式的目的。

想想這樣。假設你改變你的數據庫。您需要限制所需的代碼更改量，並將所有這些更改保留在一起，而不會影響其他應用程序。因此，通過保留模型圖層中的所有數據訪問，即使是簡單的調用，您也可以限制模型圖層所需的任何更改。如果出於任何原因繞過模型圖層，則現在必須將知道數據庫的任何代碼所需的任何更改延長，從而使此類維護比應該更復雜。

Answer 3

我喜歡爲域（模型）層中的模型持久性或服務訪問保留「契約」或接口。我把數據訪問或服務調用的實現放在另一層。

控制器被實例化爲具有服務接口的構造函數，例如， ISomeService作爲參數。控制器本身不知道如何實現服務層，但他們可以訪問它們。然後我可以輕鬆地替換SqlSomeService或InMemorySomeService。例如：ICatalogRepository與SqlServerCatalogRepositry：ICatalogRepository交給了CatalogService（ICatalogRepository，ISomeOtherDependency），這個實現將一個域（模型）圖層庫作爲參數傳遞給它的構造函數。 。

依賴注入框架使這種分離更容易。

Answer 4

我不會把數據訪問代碼放在控制器中。

基於已經說過的內容，重要的是要考慮在圖層中分層。例如，您可能在模型本身中有多個層 - 數據訪問層執行任何ORM和數據庫訪問，以及更抽象的層（代表Business Objects（不知道如何訪問其數據））。

這將允許您更輕鬆地測試系統組件，因爲它支持模擬。