为什么不注入 IServiceProvider 而不是每个单独的依赖项？

Question

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

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

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

另一个小问题是，您必须在每个单元测试中为服务容器创建一个模拟，这不是一个大问题，但肯定会很烦人。

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