傳統的3層架構vs 3層IOC

我正在構建一個包含表示層（PL），業務邏輯層（BLL）和數據訪問層（DAL）的3層架構。
傳統的3層體系結構邏輯規定BLL應充當PL和DAL之間的中介。 PL甚至不應該意識到存在數據庫，而DAL不應該意識到存在BLL或PL。上述
傳統的3層架構vs 3層IOC

實現如下

PL 項目會產生3種不同的物理項目之間的以下依賴性 - > BLL DLL

BLL 項目的參考 - > DAL的參考DLL

DAL 項目 - >編號

然而施加IOC的BLL和通過限定在BLL接口爲DAL實現和通過構造注射使用DI的DAL之間的概念將改變依賴如下

PL 項目 - > BLL DLL，DLL DAL的參考（對於具體類型的DI到BLL對象的構造函數）

BLL 幻燈的參考CT - >無參考

DAL 項目 - > BLL DLL的引用（BLL實現的接口）

那麼，國際奧委會和衝突中傳統的3層？

理想情況下，我想通過DI維護我的IOC，同時實現以下目標。

PL 項目 - > BLL DLL的參考

BLL 項目 - >無參考

DAL 項目 - > BLL DLL的參考

你是如何做到這一點的？

來源

2012-07-05 devanalyst

老問題，但我認爲這個其他的答案可以幫助：http://stackoverflow.com/questions/9501604/ioc-di-why-do-i-have-to-reference-all-layers-assemblies-在進入應用程序。基本上，你不希望你的BLL引用DAL，而是使用你的IoC容器注入它。因此，你的組合根（應用程序入口點，可能在PL項目中）會引用所有的DLL，或者你使用晚期綁定。 –

首先，您可以考慮使用接口去耦您的圖層，並且可以將接口分離爲多個獨立的dll。這樣，每個圖層只依賴於下面圖層的界面。

我也不確定爲什麼你需要從DAL到BLL的耦合？這是爲了回電嗎？你不能使用事件嗎？

假設所有3層都在運行，並假設你的PL是你的應用程序的「入口點」（組合根），IMO通常的依賴關係，如果你用PL中的引導代碼分離出接口，是：

PL =>引用BLL和DAL（混凝土和接口），和IoC容器
BLL參考DAL（或只是所述的接口，如果適用的話）
DAL沒有相關性（儘管通常將依賴於DTO/POCO /實體）

的PL可卸載的IOC配置到一個引導程序的DLL，導致：

PL =>引用BLL接口和引導程序
引導程序=>參考一切和IoC容器
BLL = >參考DAL接口
DAL =>沒有相關性（儘管通常將有DTO/POCO /實體的依賴性）

使用某些容器時，可以避免通過using configuration, or convention引用引導程序中的所有dll的要求。但是，這些dll顯然仍然需要與您的應用程序一起部署。

來源

2012-07-05 05:50:45 StuartLC

@@ nonnb，你提到DAL在兩個選項中都沒有依賴關係。但我做了一個國際奧委會，我在我的BLL中定義了IRepository接口。任何必須使用BLL的DAL都需要實現這些接口。邏輯是任何數據庫，因此DAL只是BLL實體的存儲，因此DAL應該依賴於BLL而不是其他方式。 – devanalyst

事後看來，OP可能會將埃文斯風格的域模型稱爲BLL，因此需要從DAL引用域。另一種選擇是在DAL中使用單獨的'貧血'DTO PO [CJ] Os進行再水化。這些可以映射到/從BLL /域模型。像Automapper這樣的工具可以簡化編碼。 DAL和BLL都會引用DTO – StuartLC

傳統的3層架構vs 3層IOC

回答

相關問題