爲什麼腳手架的MVC應用程序在控制器中有數據訪問

這是一個普遍的問題：當您使用實體框架搭建一個項目時，控制器將使用數據庫連接並將類似ID的東西傳遞給它並將模型返回到您的視圖。爲什麼腳手架的MVC應用程序在控制器中有數據訪問

它不應該將ID傳遞給您的模型，然後處理查詢邏輯？

這是我在MVC數據訪問的理解應該在你的模型中這樣做有類似以下內容：

public ActionResult Customer(int id) 
{ 
    View(db.Customers.FirstOrDefault(x => x.id = id)) //Where this view accepts a CustomerModel 
}

應該

public ActionResult Customer(int id) 
{ 
    var model = new CustomerModel(id) //Get customer logic is done within the model 
    View(model) 
}

我看到了很多的第一個例子中當建立一個腳手架的項目。特別是對於自動生成的Edit功能。這些CRUD操作不應該放在模型中嗎？或者這是Entity Framework獨有的東西？

如果您將EF排除在等式之外，那麼將處理模型中的所有CRUD函數是設計它的正確方法？

2015-11-19 Zach M.

您正在混淆MVC模式與Microsoft框架MVC。可以理解的，當然，鑑於微軟選擇的名稱，但實際上，ASP.NET MVC只是非常鬆散地遵循MVC模式。

即是說，大多數來ASP.NET MVC的新開發人員看到的模型，僅僅是一個實體。它僅僅是一個DTO類，可以在數據從數據庫中進行混洗時保存數據。它應該絕對不是包含查詢邏輯。

大多數ASP.NET MVC開發人員最終都會添加服務/存儲庫層並查看模型。這三個實體，服務/存儲庫層以及各種視圖模型一起構成了MVC模型。服務/存儲庫負責處理CRUD功能和其他與數據庫相關的業務邏輯，而視圖模型則是負責UI相關的業務邏輯。該實體只是EF可以填充數據的東西。

2015-11-19 17:10:01

這無疑使事情變得更加清晰。我沒有把兩者區分開來。所以如果你想遵守行業MVC標準，你會簡單地創建自己的模型來實現或擴展實體嗎？通過這種方式，您可以在保持控制器對數據訪問無視的同時，執行所有的粗暴操作。 –

這幾乎是你的服務/存儲庫。它將是一個類，它提供了一組返回特定數據集或執行應用程序所需的特定操作的方法。控制器*將*依賴於這個類，但實際的數據庫邏輯可以不在控制器之外。 –

非常好，這回答了我在MVC和微軟版本之間看到的很多差異。 –

IMHO，你混合（至少）兩個概念：

控制者（通過業務領域層）建立兩者之間的聯繫。

AND NO：視圖不需要（不能）看到數據層。

最後：這個問題可能是基於意見的（見imho）。

2015-11-19 17:08:18 tschmit007

這確實是一個偏好問題。就我個人而言，我喜歡將我的模型保留爲愚蠢的對象，但您可能更願意將您的模型用於CRUD。通過將ID傳遞給構造函數來獲取客戶的例子並不是最好的想法，因爲您將在模型中對DbContext產生嚴重依賴，這將使測試變得困難並導致問題。

腳手架控制器直接與DbContext進行交互，只需要儘可能少的數量並保持簡單。如果您需要額外的邏輯，您可以將其重構到其他地方。

2015-11-19 17:15:10 timothyclifford

回答