c# - 为什么不注入(inject) IServiceProvider 而不是每个单独的依赖项？

Question

我想知道为什么不显式使用 IServiceProvider 来解决依赖关系，而不是单独注入(inject)每个依赖关系。换句话说，为什么要使用这种方法:

public class A 
{
    private B _b;
    private C _c;
    private D _d;
    private E _e;

    public A(B b, C c, D d, E e)
    {
        _b = b;
        _c = c;
        _d = d;
        _e = e;
    }
}

不是这个:

public class A 
{
    private B _b;
    private C _c;
    private D _d;
    private E _e;

    public A(IServiceProvider sp)
    {
        _b = (b) sp.GetService(typeof(b));
        _c = (c) sp.GetService(typeof(c));
        _d = (d) sp.GetService(typeof(d));
        _e = (e) sp.GetService(typeof(e));
    }
}

请注意，我可能不会为所有 类型调用GetService，某些类型可能实际上是可选的(即有时使用，有时不使用) .

第二种方法的优点是，如果 A 的依赖关系发生变化，我们不需要在调用 A 的构造函数的每个地方都进行更改，并且我们不需要无论我们在哪里调用构造函数，所有依赖项都已经可用。

MS 似乎在以下文章中反对这样做:https://learn.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.2#recommendations他们提到要避免使用服务定位器模式而不是 DI，但我们这里不是仍在使用 DI 吗？无论如何，同样的事情不会在后台发生吗？

Answer 1

有几个原因。当您使用依赖项注入(inject)时，您就是在赋予 DI 容器为您准备依赖项的责任。这些类不应该关心您的依赖项是如何创建的。如果切换到不同的 DI 库，则必须更改所有类中的构造函数。

另一个小问题是您必须在每个单元测试中为您的服务容器创建一个模拟，这不是一个大问题，但绝对是一件令人讨厌的事情。

最后，当您必须将依赖项传递给嵌套类时，您的代码将变得非常奇怪，更不用说您想要继承的任何时候了。