dependency-injection - Ninject:使用哪种注入(inject)模式来注入(inject)多个依赖项？

Question

如果我有 10 个依赖项我需要注入(inject)并且不想在构造函数中有 10 个参数，我应该使用哪种注入(inject)模式？

public class SomeClass
{
    private IDependency1 _dependency1;
    private IDependency2 _dependency2;
    private IDependency3 _dependency3;
    //...
}

我应该使用setter方法注入(inject)吗？

public class SomeClass
{
    private IDependency1 _dependency1;
    private IDependency2 _dependency2;
    private IDependency3 _dependency3;
    //...

    [Inject]
    public void SetDependency1(IDependency1 dependency1)
    {
        _dependency1 = dependency1;
    }
    //...
}

还是属性注入(inject)？

public class SomeClass
{
    [Inject]
    public IDependency1 Dependency1 { private get; set; }
    [Inject]
    public IDependency2 Dependency2 { private get; set; }
    [Inject]
    public IDependency3 Dependency3 { private get; set; }
    //...
}

根据 Ninject wiki，只写像上面这样的属性被认为是不好的做法，但它和上面的 setter 方法注入(inject)不一样，只是代码更少？

哪种模式最适合这种情况？

Answer 1

构造函数注入(inject)始终是进行依赖注入(inject)的首选方式。只有在无法进行构造函数注入(inject)时才应该恢复属性注入(inject)，例如，在处理依赖循环时(其中 A 依赖于 B，B 依赖于 A)。

您可能会问这个问题的原因是，因为您在编写和维护具有这么多参数的构造函数时变得不舒服。

拥有这么多参数是一种反模式(constructor over-injection anti-pattern)，但解决此问题的方法不是回退到属性注入(inject)。一般来说，当有这么多依赖时，有问题的类会做很多事情。它违反了 Single Responsibility Principle .在违反 SRP 时，拥有数量令人尴尬的依赖项实际上是最少的问题。违反 SRP 的代码更难理解、维护和测试。我可以谈谈经验。每次我发现自己对为类(class)编写单元测试感到不舒服时，我的设计就有问题。除了 SRP 之外，还有其他四个重要原则，分组在 SOLID 中。首字母缩略词。遵循这些原则，您将成为拥有更多可维护软件的更快乐的程序员。

当一个类违反 SRP 时，通常这意味着它应该被分成多个类，每个类都有一个单一的职责。当你这样做时，你会看到依赖的数量减少了。