在使用依赖注入容器时明确依赖答案

【问题标题】：Making dependencies explicit while using a dependency injection container在使用依赖注入容器时明确依赖
【发布时间】：2012-03-18 05:46:06
【问题描述】：

依赖注入的一大优点是类的依赖在其接口（即构造函数）中显式定义。但是，如果使用依赖注入容器，则这些依赖中的许多会被合并为一个依赖（容器）。因此，一个类的许多真正的依赖关系都隐藏在容器后面。如何避免这种情况，以便在使用依赖注入容器时仍显式定义依赖关系？

【问题讨论】：

没有一致使用构造函数注入的类依赖于 DI 容器。您可以使用容器来连接此类类，但您也不必这样做。怎么还不够明确？
如果类 A 是使用 DI 容器构建的，并且 A 有一个 B，B 有一个 C，那么 C 如何访问其所需的依赖项？调用堆栈下几级的类如何访问依赖关系？
他们也使用构造函数注入。所以如果 C 依赖于 D，它会通过它的构造函数来获取它。
所以我所有的类都应该有如下构造函数：__construct(DatabaseAdapter $db, Cache $cache, Logger $logger, ...) ?
是与否：它们很可能不应该依赖于缓存、记录器和其他横切关注点：stackoverflow.com/questions/1708992/…stackoverflow.com/questions/8426132/…

【解决方案1】：

看来您可以在 bean 定义中使用“depends-on”属性在代码中添加显式依赖项。我在这里发现了一个类似的问题

【讨论】：

【解决方案2】：

是也不是，这真的取决于你的依赖注入容器是如何工作的。

我认为这种代码没有任何问题：

class Class1 {
    /**
     * @Inject
     * @var Class2
     */
    private $class2;
}

即使依赖项将由容器注入，Class1 依赖于Class2 的事实是相当明确的。（这里使用的依赖注入容器是PHP-DI）

【讨论】：

【解决方案3】：

我在 3 年前问过这个问题，后来开始理解并喜欢静态类型语言中的 DI。

当我问这个问题时，我似乎不明白“服务定位器”和“依赖注入容器”（DIC）之间的区别。

DIC 在应用“下方”运行，并负责构造对象和构建对象图，通常在引导期间但如果完全引导，则在应用之前。 类不应该知道 DIC 并且不应该依赖它。 DIC 应该构造类的所有依赖项并注入它们，就好像该类是手动实例化的一样。

服务定位器是在系统中传递并用于查找依赖项的对象。使用服务定位器会掩盖依赖关系（我在学习这些东西时注意到的原始问题）并创建系统范围的依赖关系（即服务定位器本身）。

一般来说，我会避免使用服务定位器模式（有人称其为“反模式”）。使用像 Ninject 或 Symfony 2 的 DIC 这样好的 DIC 将使您的类专注于其中的业务逻辑 - 而不是寻找依赖关系。

阅读 Martin Fowlers 关于依赖注入的文章：http://www.martinfowler.com/articles/injection.html

【讨论】：