MarkDown/dotnet/DI/静态类中的依赖注入.md

在静态类中使用.NET Core DI

你可能会遇到这样的情况：你需要在一个静态类里面解析一个依赖关系，但是对于静态类，你只能使用静态构造函数，而这个构造函数对于.NET core 来说是无效的，无法用于构造函数注入。

在工作中，让我们考虑使用 AutoMapper 来配置你的实体之间的映射，以及不同类型的视图模型或 DTOs，为了做到这一点，你可以在 ConfigureServices 中配置 AutoMapper 本身，并且在 AutoMapper.Extensions.Microsoft.DependencyInjection 的帮助下，你会得到一个方便的方法来扫描你提供的程序集来添加 "Profile"，就像这样:

现在要使用 AutoMapper，你必须获得 IMapper 的引用，你可以很容易地将其添加到 Controllers 中作为构造函数注入:

由于扩展方法，它们将逻辑封装在一个声明性的可重用的名字中，像这样，你可能也想创建自己的扩展方法。那么你可能会想，好吧，我可以把这些逻辑封装到我自己的扩展方法中，但是按照扩展方法的要求，你必须在静态类中声明它，而且它必须是一个静态方法，所以我们创建一个；为了做到这一点，我们创建一个基础接口，我们所有的 DTO 都应实现这个接口:

现在我们需要用 IMapper 提供这个扩展方法类，但是怎么做呢，我们不能使用构造函数注入，首先我们创建一个函数，我们可以调用这个函数来设置这个依赖，我们也可以使用属性注入:

现在我们的扩展方法类已经准备好了，我们只需要一种方法来调用那个 Configure 方法来提供它的 IMapper 实例。

为了克服这个问题，我们可以使用我们的应用入口点来提供这种静态类及其依赖关系，但是有一个常见的错误，我自己曾经陷入其中；你可能首先想到的地方是在 ConfigureService 函数中:

如果你注意到 BuildServiceProvider 下面有一条方格线，这是一个警告，你应该小心它的内容。

如果我们在这里构建服务提供者，它会创建一个新的 Singletones，这个警告提供的解决方案并不明确，但已经很接近了，比较好的地方是在 Configure 函数中，这里已经构建了服务提供者，你可以从它那里消耗任何服务，所以我们把我们扩展方法类的 configure 函数移到那里:

现在，我们已经远离了在 ConfigureService 函数中手动操作会产生的额外作用域，我们现在可以享受到更清晰的扩展方法语法，以及 DI。