3

如果我有 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 方法注入不一样，只是代码更少吗？

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

4

1 回答 1

9

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

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

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

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

于 2012-09-18T11:58:30.533 回答