为什么不注入 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 的构造函数的每个地方进行更改，并且我们不需要拥有所有无论我们在哪里调用构造函数，依赖项都已经可用。

Answer 1

有几个原因。当您使用依赖项注入时，您将让 DI 容器负责为您准备依赖项。这些类不应该关心如何创建依赖项。如果您切换到不同的 DI 库，则必须更改所有类中的构造函数。另一个小问题是，您必须在每个单元测试中为服务容器创建一个模拟，这不是一个大问题，但肯定会很烦人。最后，当您必须将依赖项传递给嵌套类时，您的代码将变得非常奇怪，更不用说您想要继承的任何时候了。

Answer 2

这称为服务定位器模式 ->它有一些优点和缺点（在文章中描述），但它被广泛视为一种反模式。你声明你自己调用构造函数（正如new SomeService(...)我猜测的那样），这是不使用 DI （或仅部分使用）的标志。