使用依赖注入容器时明确依赖关系

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

2012-03-18 orourkedd

没有一贯地采用构造器注入类取决于DI容器。你*可能*使用一个容器来连接这些类，但是你不需要。这不够明确吗？ – 2012-03-18 08:15:02

如果A类是使用DI容器构造的，并且A具有-A B，B具有C，那么C如何访问其所需的依赖关系？如何将类放在调用堆栈访问相关的几个级别上？ – orourkedd 2012-03-18 16:10:31

它们也使用构造函数注入。所以如果C依赖于D，它就通过它的构造函数获取它。 – 2012-03-18 17:21:42

我3年前问这个问题，并有因为来了解和热爱DI在静态类型语言。

它看起来就像当我问这个问题我不明白“服务定位器”和“依赖注入容器”（DIC）之间的差异。

甲DIC操作“下面”的应用程序，负责构造对象，建立对象图，通常在自举，但如果充分自举的应用之前。 班级不应该知道DIC，不应该依赖它。 DIC应该构造该类的所有依赖关系，并将它们注入，就好像类正在手动实例化一样。

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

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

2014-10-08 20:25:37 orourkedd

看来你可以使用'取决于-on属性在bean定义添加到您的代码中显式依赖。我发现这里

2012-03-18 07:10:10 sachinrahulsourav

是一个类似的问题也没有，这真的取决于你如何依赖注入容器的作品。

我看不出有任何问题，这种代码：

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

即使依存度将通过容器注入，即Class1取决于Class2其实是相当明确的。（这里使用依赖注入容器是PHP-DI）

2012-11-12 09:15:42

回答