如何避免循環依賴：DAL.DbContext.DbSet <BLL.Model>

如果DbContext位於DAL中，則DbSets的泛型類型參數不能是BLL類（域模型）。什麼是分離這些層的最佳實踐方法？ DAL中的額外模型？接口？如何避免循環依賴：DAL.DbContext.DbSet <BLL.Model>

2013-04-10 Benjamin

我通常認爲域模型是一個單獨的層。
如果我們看一下經典的MVC paradaigm，那麼View和Controller都會使用該模型。
沒有理由爲什麼它不應該由DAL使用。

但是，Model不會引用DAL;針對數據存儲的所有操作都將由控制器完成。

這樣的事情一般流程將是─
用戶與View View交互調用DAL上Controller Controller方法用於檢索Model對象 Controller調用上Model對象的方法，節省了他們（使用DAL ），並返回一個答案View

來源

2013-04-10 18:44:58

您是否在MVC和BLL-DAL關係之間做類比？我認爲MVC中的M是一個獨特的表示模型，而不是BLL域模型。我知道它可以完全相同，但我想知道關於去耦層的最佳實踐。 – Benjamin 2013-04-10 18:47:42

M絕對是模特，與演示無關;請參閱http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html（作者將數據訪問放入模型層，這也是允許的） – 2013-04-10 19:05:51

我不明白BLL和DAL在你的場景中。 – Benjamin 2013-04-10 19:50:22

如果你在做DDD，我相信存儲庫（至少是它的接口）是你的業務/領域層的一部分。您的存儲庫實現將是一個單獨的程序集，它必須引用該業務/域層。所以你的DAL知道你的業務對象，但不是相反。要執行依賴注入，您可能需要在您的DAL層中配置您的容器以將Repository用於您的IRepository接口。如果你需要一個工作模式單元，你的界面可能也必須成爲業務層的一部分。您的實施再次在您的DAL中，DAL將適當地配置DI容器。這實際上是我對存儲庫模式不喜歡的事情之一，因爲您需要確保您的界面用戶正確管理IUnitOfWork，或者需要一些東西來包裝存儲庫。

在傳統的n層架構中，情況有些不同。在這種情況下，您的業務層可以與DAL交談，並且我通常構建DAL以使DTO代表數據庫中的一行數據。然後，業務層將使用這些DTO來爲業務對象提供水分（或者如果您使用的是CSLA.Net之類的業務對象，則知道如何爲自己提供水分）。

無論哪種方式，不應該有一個情況，你最終的循環引用。

來源

2013-04-10 18:56:40 Andy

謝謝。清晰簡潔，但我仍在處理它。那麼對於DDD把IRepository（和IUnitOfWork呢？）放在BLL工程中，但是我需要告訴BLL IUnitOfWork目前是DbContext等等。那就是依賴注入？一個單獨的組件？你可以解釋嗎？ – Benjamin 2013-04-10 19:34:05

@Benjamin我已經更新了我的答案，包括你的新問題。 – Andy 2013-04-11 15:18:43

BLL或Domain Layer不應該擔心數據訪問技術細節，BLL應該是技術獨立的。如果你想堅持實體框架，你應該生成POCO實體並將它們移動到單獨的層，這樣你就可以避免循環引用。

來源

2013-04-12 04:17:41 Brainchild

如何避免循環依賴：DAL.DbContext.DbSet <BLL.Model>

回答

相關問題