DBContext，Repository和UnitOfWork應該在哪一層？

Question

我想在項目中使用分層體系結構和EF，Repository和UoW模式。

DBContext，Repository和UnitOfWork應該在哪一層？

DAL or BLL？

Answer 1

我會把你的DbContext實現放到你的DAL（數據訪問層）中。您可能會對此有不同的看法，但我不會實施存儲庫或工作模式單元。從技術上講，DBContext是工作單元，IDbSet是一個存儲庫。通過實現你自己，你在抽象之上添加一個抽象。

更多關於此here和here。

Answer 2

DAL是數據訪問層的首字母縮略詞。 DbContext，存儲庫和Unit Of Work與處理數據有關，因此您應該將它們放在DAL中。

Answer 3

「應該」在這裏可能不是正確的詞，因爲在這個問題上有很多意見。 如果要實現這些模式出了書，我會從ASP.NET傢伙看看這個鏈接： https://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

但其實我已經開始層這樣的：

控制器/邏輯< - 創建和轉換業務邏輯和邊界對象。

庫< - 凡涉及持久性和轉化實體和查詢邏輯對象

商店< - 當存儲機制的實際實現居住。這是從一個接口後面抽象出來的。

這種方式利用了這樣一個事實，即業務邏輯和存儲庫邏輯都是可測試的，分離的並且可以自由地使用任何持久性機制 - 或者缺乏這種機制。沒有其他應用程序知道它的任何事情。

這是與其他模式的關係，這只是我對此的看法。

DbContext不應該跨越DAL的邊界，如果您想將您的存儲庫或工作單元放在那裏，您可以自由使用，只是不要讓它們向上泄漏它們的細節或依賴關係。在我看來，DbContext應儘可能縮小範圍，儘可能保持乾淨 - 你永遠不知道上下文的位置......請穿上保護！但是，如果你有一個異步的，多線程的，多節點的大應用程序，使用這些DbContext到處傳遞它們，你將會遇到一般的併發和數據競爭問題。

我喜歡做的是開始一個InMemory存儲，我注入到我的控制器。只要該商店開始爲多個實體提供服務，並且持久性邏輯越來越複雜 - 我將其重構爲頂層存儲庫。一旦我所有的測試都通過了，並且按照我的要求進行工作，我就開始創建該商店的基於數據庫或文件系統的實現。

我的意見再一次在這裏，因爲這是一個相當普遍的問題，它只有很少的「真實」的答案，只是很多意見。

對此的大多數意見都是有效的，他們只是有不同的優缺點，重要的是要弄清楚你需要哪些優勢，以及你如何處理弱點。

Answer 4

您的存儲庫應該有對DbSet<T>對象的引用，並且一旦從一個或多個存儲庫添加，更新或刪除，您應該調用UnitOfWork中的SaveChanges。因此，您應該將DbContext放入工作單元實施中。