传统的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

回答

相关问题