如果Entity Framework/DbContext是DAL/Repository，它在三層體系結構中適合哪裏？

我一直在閱讀有關StackOverflow和其他網站上關於最佳體系結構實踐的文章，並且存在許多相互矛盾的想法和觀點。如果Entity Framework/DbContext是DAL/Repository，它在三層體系結構中適合哪裏？

我終於找到了一種方法，但我很難決定在哪裏放置EF對象（DbContext，Fluent APIs，種子數據等）。這裏是我目前有：

ASP.NET MVC項目：實際的Web項目。包含標準視圖，控制器和視圖模型（位於型號文件夾內）。

域模型項目：包含定義數據庫（域）對象的所有POCO類。目前，沒有提及或引用任何EF對象。

服務層項目：包含每種類型的域對象（例如，IProductService，IOrderService等）的服務對象。每個服務引用EF對象（如DbSets）並處理業務規則 - 例如，添加產品，獲取產品，將產品附加到訂單等。

所以問題是，在這種配置中，EF類在哪裏？最初我在服務層思考過，但這似乎沒有道理。然後我想把它們放在域模型層中，然後它將域模型綁定到EF上，EF本質上是一個DAL/Repository。最後，我想爲EF創建一個單獨的DAL項目，但考慮到它可能包含3-4個文件（DbContext和其他一些小文件），似乎是一個巨大的浪費。

任何人都可以提供任何指導？

來源

2013-06-01 Amberite

什麼推動你創建三個項目，而不是一個？ –

更好的可擴展性。通過一個單獨的域模型項目和一個服務項目，您可以擁有另一個應用程序（例如，一個WinForms應用程序），該應用程序可以輕鬆使用域和業務邏輯，而無需複製代碼。另外，如果有WinForms應用程序和MVC應用程序，則只需在一個地方而不是兩個地方進行業務規則更改等操作。 – Amberite

因爲它是冗餘的，所以不需要域模型。 EF類可以直接充當域模型，並將它們轉換爲視圖模型，同時將其發送到視圖。 EF可以分爲不同的類庫。他們中的大多數使用存儲庫模式以及任何ORM，如果他們進行替換，這很容易。但我已經看到了使用存儲庫模式的批評，請檢查this。

來源

2013-06-01 05:34:32 Sunny

我使用EF Code First，所以我自己創建了POCO類。然而，我的印象是，我的領域模型應該是純粹的POCO類，EF DbContext等人應該生活在其他地方。這是錯的嗎？ – Amberite

像Sunny一樣提到 - 帶上你的POCO類並在你的解決方案中創建一個新的項目，它只包含你的POCO類（不是你的DbContext）..該程序集可以非常輕便，並且不需要對EF有任何依賴。。你的DbContext將會在你的WPF/WinForm/WebForm/MVC/Silverlight/Whatever-assembly中取決於EF。這是最好的方法，也是您在首次展示EF代碼時通常會看到的一個示例。 –

@DerekCurtis：問題是，如果我把DbContext放在MVC項目中，那麼服務層需要引用MVC項目，而MVC項目也需要引用服務層。看起來像一個循環參考？ – Amberite

這裏是我做的：

數據：

有一類從繼承的DbContext。
- 它有所有的數據集。
- 重寫OnModelCreating。
- 映射主鍵和關係。

實體：

有充分的POCO類。
- 每個屬性都裝飾有所需的數據註釋。

服務：

每個服務都有通用的方法（的GetList（），查找（），創建（），等）。

業務：

來自客戶端的調用，協調使用服務來執行特定任務UserChangePassword（這將檢查是否可以這樣執行，則執行任務，或在許多返回錯誤/非授權狀態他人作客戶端顯示有關任務的正確信息。這對我的情況是我記錄。

客戶端（臺式機/網絡/ WPF /等）。

我不是說這是最好的方法，我只是分享一直在爲我工作的東西。

來源

2013-06-01 06:12:55 Esteban

如果Entity Framework/DbContext是DAL/Repository，它在三層體系結構中適合哪裏？

回答

相關問題