Question

我对依赖注入模式有疑问。我的问题是...... 如果我去构造函数注入，为我的类注入依赖项，我得到的是一个有很多参数的“大”构造函数。如果是的话。我在某些方法中不使用某些参数？ IE浏览器。我有一个暴露许多方法的服务。以及一个包含10个参数（所有依赖项）的构造函数。但并非所有方法都使用所有依赖项。某些方法只使用一个依赖项，另一个方法将使用3个依赖项。但即使使用非容器，DI容器也会解决所有问题。

对我来说，这是使用DI容器的性能损失。这是真的吗？

Answer 1

看起来你的类做得很多，它不符合SOLID中的S（单一责任原则），也许你可以将类拆分为多个较小的类，而且依赖性较小。并非所有依赖项都被所有方法使用的事实表明了这一点。

Answer 2

通常，注入许多依赖项的性能损失很小，但这取决于您选择的框架。有些人会在运行中为此编译方法。你必须测试这个。很多依赖项确实表明你的课程做得太多了（比如Ruben所说），所以你可能想看一下。如果创建通常不使用的依赖项实例会导致性能问题，则可能需要将工厂作为依赖项引入。我发现使用工厂可以解决许多关于依赖注入框架使用的问题。

// Constructor
public Consumer(IContextFactory contextFactory)
{
    this.contextFactory = contextFactory;
}

public void DoSomething()
{
    var context = this.contextFactory.CreateNew();
    try
    {
        // use context here

        context.Commit();
    }
    finally
    {
        context.Dispose();
    }
}

Answer 3

实际上，在构建DI容器时，无法知道运行时使用了哪些方法。您必须处理性能损失，或者如果您知道在很多情况下只使用了几个依赖项，您可以将容器拆分为几个注入的依赖性较小的小容器。

Answer 4

您还可以隐藏延迟提供程序后面的一些尚未需要的依赖项。例如：

public DataSourceProvider implements Provider<DataSource> {

    public DataSource get() {
         return lazyGetDataSource();
    }

}

Provider interface是javax.inject包的一部分。

Answer 5

正如rube说的那样，你应该回顾一下你班级的设计，坚持SOLID原则。

无论如何，如果没有必要，我习惯于使用属性setter依赖而不是构造函数。这意味着您可以为您需要的每个家属创建一个属性。这也有助于测试该类，因为您可以只将所需的依赖项注入到正在进行的测试的上下文中，而不是将所有依赖项存根，即使您不需要它

依赖注入问题

5 个答案: