Ninject:用于注入多个依赖项的注入模式？

Question

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

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

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

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

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

还是物业注入？

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方法注入不一样,只是更少的代码？

对于这种情况,哪种模式最有意义？

Answer 1

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

您可能会问这个问题的原因是,因为您在编写时会感到不舒服并且使用那么多参数来维护构造函数.

拥有那么多参数是一种反模式(构造函数过度注入反模式),但解决这个问题的方法不是回归属性注入.一般来说,当拥有那么多依赖关系时,所讨论的类会做很多事情; 它违反了单一责任原则.在违反SRP时,具有笨拙数量的依赖性实际上是您遇到的最少问题.违反SRP的代码更难理解,维护并且更难以测试.我可以从经验谈起.每次我发现自己在为一堂课编写单元测试时感到不舒服,我的设计出现了问题.除了SRP之外,还有其他四个重要原则,分为SOLID首字母缩略词.遵循这些原则,您将成为一个拥有更多可维护软件的更快乐的程序员.

当一个类违反SRP时,一般来说这意味着它应该分成多个类,每个类都有一个责任.执行此操作时,您将看到依赖项的数量下降.