更好的方法是:為DbContext創建自己的包裝器或在Controller中使用DbContext

asp.net-core asp.net-core-mvc c# entity-framework-core

在我的項目中,我使用實體框架7asp.net mvc 6 \ asp.net 5 。我想為自己的模型創建CRUD

我怎樣才能做得更好:

  1. 使用控制器中的dbcontext。在下面的鏈接中作者解釋說這種方式更好,但它是否適合控制器?
  2. 製作自己的包裝紙。一些最佳實踐寫了什麼是最好的自己的存儲庫。

我不會改變其他東西的ef,所以不要介意,即使有一個強大的連接來訪問特定實現的數據,我知道在ef7 dbcontext中立即實現了工作單元和存儲庫模式。

一般承認的答案

您的問題的答案主要是基於意見的。在回答許多其他問題之前,沒有人能夠明確地說“一種方式比另一種方式更好”。您項目的規模/範圍/預算是多少?有多少開發人員會參與其中?它只有(基於視圖的)MVC控制器,還是它有(基於數據的)API控制器?如果是後者,MVC和API動作方法之間會有多少重疊,如果有的話?是否有任何非網絡客戶端,如WPF?您打算如何測試應用程序?

實體框架是一種數據訪問層(DAL)工具。控制器是HTTP客戶端請求和響應處理工具。除非您的應用程序是純CRUD(這是值得懷疑的),否則當您通過HTTP接收Web請求和使用EF將該請求的數據保存到數據庫之間時,您可能需要進行某種業務邏輯處理(字段X是必需的,如果為字段Y提供數據,則還必須為字段Z提供數據等。因此,如果您直接在控制器中使用EF代碼,這意味著您的業務處理邏輯幾乎肯定會與控制器一起出現在控制器中。

我們這些在使用.NET開發非平凡應用程序方面擁有相當豐富經驗的人傾向於發展出這樣的觀點:由於在實現這樣的設計時出現某些困難,因此控制器中既不存在業務也不存在數據訪問邏輯。例如,當您將web / http請求和響應邏輯以及業務邏輯和數據訪問邏輯放入控制器時,您最終必須從控制器操作本身測試所有這些應用程序方面(這明顯違反了Single責任原則,如果您關心SOLID設計)。另外,假設您使用返回視圖的控制器開發傳統的MVC應用程序,然後決定將應用程序擴展到其他客戶端,如iOS / android / WPF /或其他不了解MVC視圖的客戶端。如果您決定實施一組基於WebAPI數據的輔助控制器操作,則至少會在兩個位置複製業務和數據訪問邏輯。

儘管如此,這並沒有決定保持控制器中的所有業務和數據訪問邏輯本質上比替代設計“更糟糕”。在設計Web應用程序的體系結構時,您做出的任何決定都將具有優勢和劣勢。無論您選擇哪條路線,總會有權衡。將所有應用程序代碼保存在控制器中的優點包括降低成本,降低複雜性,從而縮短產品上市時間。對於非常簡單的應用程序來說,過度設計複雜的體系結構是沒有意義的。不幸的是,我個人從未有過開發一個簡單的應用程序的樂趣,所以我在“一般意見”的船上,將控制器中的業務和數據訪問代碼保留“可能不是”一個很好的長期設計決策。

如果您真的對替代品感興趣,我建議您閱讀這 兩篇文章 。它們是關於如何實現控制器可以使用的命令和查詢(CQRS)模式的良好入門。 EF確實實現了存儲庫和開箱即用的工作模式,但這並不一定意味著您需要“包裝”它以便將數據訪問代碼移到控制器之外。祝您的項目做出這些決定。

public async Task<ActionResult> Index() {
    var user = await query.Execute(new UserById(1));
    return View(user);
}

熱門答案

通常我更喜歡使用Repository模式和UnitOfWork模式( http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository - 並且 - asp-net-mvc-application中的工作模式 - 我在UnitOfWork實例對像中實例化DbContext,然後在存儲庫中註入DbContext。之後,我在控制器中實例化UnitOfWork,控制器對DbContext一無所知:

public ActionResult Index()
{
    var user = unitOfWork.UsersRepository.GetById(1); // unitOfWork is dependency injected using Unity or Ninject or some other framework
    return View(user);
}



許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因