依赖注入 vs 程序集依赖答案

【问题标题】：Dependency injection vs assembly dependencies依赖注入 vs 程序集依赖
【发布时间】：2015-10-11 08:13:15
【问题描述】：

假设我有以下项目结构：

Application <-> BusinessLogic <-> DataAccessLayer

我已经准备好使用穷人依赖注入的所有类型，现在我想介绍使用 Unity 的真正类型。但是我正在努力将依赖容器及其配置放在哪里（我想我会从代码中配置它）。

目前，使用容器实际实例化类的唯一程序集是应用程序。所以我有以下依赖关系图：

我在这里有循环引用，所以将 DI 放在 Application 中似乎是合法的。但是我必须引用 DataAccessLayer 并且这是我不想创建的依赖项。我应该如何解决这个问题？

【问题讨论】：

"DI" 不应该依赖于任何这些。由客户端（在您的情况下为Application）使用 DI 注册依赖项。
@haim770 “DI 使用 *”我的意思是：“从 * 注册类型的人必须有权访问它”。如果我从Application 注册类型，我必须创建对DataAccessLayer 的依赖项，但我不想这样做（如果可能的话，至少）。
即使您将注册委托给 DI 项目，您也不会真正获得任何收益，因为最终应用程序依赖于这些程序集，并且它们将被引用。也许您真正追求的是使用程序集扫描 (autoregistration.codeplex.com) 进行动态注册？
@Spook 我不知道您为什么会遇到循环引用之类的问题？您在图层中使用服务定位器模式吗？使用 DI 容器时使用服务定位器模式不是正确的方法

【解决方案1】：

如果您想使用 DI 容器，那么您应该只在应用程序本身中使用它，而不是在您的其他类库（例如 BusinessLogic 和 DataAccessLayer）中使用它。应用程序中您构成对象图的位置称为Composition Root。

引用那篇文章：

只有应用程序应该有组合根。库和框架不应该。

既然你已经准备好你的类来启用穷人 DI（现在称为Pure DI），你应该没问题。 DI 现在已在您的库中启用（请注意，DI 和 DI 容器是不同的东西）。

您的应用程序现在可以将所有类库中的所有内容连接在一起，即使这意味着您的应用程序项目将需要引用所有其他类库。

在我看来，最好不要使用 DI 容器（即使在应用层），请参阅 this article 了解原因。

【讨论】：

【解决方案2】：

这样，相对较高的层与较低的层屏蔽，一切都正确注册。对于 A 层来说，DL 甚至是存在的一个实现细节。它只知道BL层。

【讨论】：