依赖注入问题

我有一个关于依赖注入模式的问题。我的问题是... 如果我去构造函数注入，注入我的类的依赖关系，我得到的是一个“大”的构造函数与许多参数。如果ie。在某些方法中我不使用一些参数？也就是说。我有一个暴露很多方法的服务。还有一个带有10个参数的构造函数（所有依赖项）。但并不是所有的方法都使用所有的依赖关系。有些方法只会使用一个依赖项，另一个会使用3个依赖项。但即使使用非容器，DI容器也会解决这些问题。依赖注入问题

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

来源

2010-11-03 Luka

您还可以隐藏懒惰提供者背后的一些不需要的依赖关系。例如：

public DataSourceProvider implements Provider<DataSource> { 

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

}

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

来源

2010-11-03 09:07:04

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

来源

2010-11-03 09:01:32 MatthiasG

看来你的班级正在做很多事情，它不符合SOLID（单一职责原则）中的S，也许你可以将班级拆分成多个较小的班级，而且依赖性较少。并不是所有方法都使用所有的依赖关系这一事实表明了这一点。

来源

2010-11-03 09:02:13 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(); 
    } 
}

来源

2010-11-03 10:20:51 Steven

由于rube说可能你应该复习你的课程的设计坚持固体原则。

无论如何，如果它不是真的有必要我已经习惯了属性设置依赖而不是构造函数。这意味着您可以为每个需要的依赖项创建一个属性。这也有助于对类进行测试，因为您只需将所需的依赖项插入到正在执行的测试的上下文中，而不是将所有依赖项即使不需要它也删除掉

来源

2010-11-03 11:46:44

可变状态应该完全避免成本。 – 2010-11-03 11:52:27

我同意你的意见。在我的回答中，我同意Rube说他可能会评论他的班级设计。我的第二个评论只是一个实用的:-) – 2010-11-03 17:47:42

依赖注入问题

回答

相关问题