【2】.NET6最通俗易懂的依赖注入之生命周期
这篇文章是 ASP.NET 6 依赖注入系列文章的第二篇。
在上一篇文章中，我们讨论了什么是依赖注入和控制反转，以及它的作用是什么。
在这篇文章中，我们先演示一下依赖注入的基本用法， 然后再讨论生命周期模式。
基本用法
.NET 依赖注入组件主要涉及两个包：
<ItemGroup> <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="6.0.0" /> <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="6.0.0" /> </ItemGroup>
Abstractions 结尾的包中定义的是接口和基础的数据类型，具体实现则是由没有 Abstractions 结尾的包来提供。
比如依赖注入组件，抽象的接口和必要的类型都定义在Microsoft.Extensions.DependencyInjection.Abstractions的包中，具体的实现则在 Microsoft.Extensions.DependencyInjection 包中。
.NET 中的很多类库和组件，在设计的时候都会考虑这种“抽象和实现”的分离。
在 ASP.NET 依赖注入系统中，我们需要通过一个由 IServiceCollection 接口表示的集合来完成服务的注册，所以我们称它为服务集合。
你可以把服务集合理解为一个服务的花名册，服务注册其实就是在这个花名册里，登记服务类型的基本信息，以便在需要的时候，依赖注入控制系统能够找到它。
通过服务集合可以创建出服务提供对象，它表示为一个 ServiceProvider 对象，如下所示：
public static class Sample01 { public interface IAccount{ } public interface IMessage{ } public interface ITool{ } public class Account: IAccount{} public class Message: IMessage{} public class Tool: ITool{} public static void Run() { // 创建服务集合 var serviceCollection = new ServiceCollection(); // 注册服务 serviceCollection.AddTransient<IAccount, Account>(); serviceCollection.AddScoped<IMessage, Message>(); serviceCollection.AddSingleton<ITool, Tool>(); // 创建服务提供对象 var serviceProvider = serviceCollection.BuildServiceProvider(); } }
这段示例代码中，有三个接口，并分别实现了三个类。
这里的每一个接口都可以认为是一项服务，而每个类则是这个服务的具体实现。
我们可以通过服务提供对象，获取任何已经注册过的服务类型的实例，如下所示：
serviceProvider.GetService<IAccount>(); serviceProvider.GetService<IMessage>(); serviceProvider.GetService<ITool>();
服务注册
.NET 依赖注入组件采用了生命周期的方式，来管理它所提供的服务实例。
所谓的生命周期，就是指由依赖注入组件创建出来的服务实例，可以存活多久。
生命周期有三种模式：瞬时（Transient）、作用域（Scoped）、单例（Singleton）。
我们在注册服务时，必须要指定服务属于哪种生命周期模式，比如刚才的代码示例：
serviceCollection.AddTransient<IAccount, Account>(); serviceCollection.AddScoped<IMessage, Message>(); serviceCollection.AddSingleton<ITool, Tool>();
从注册方法的名称Addxxxx可以看出，注册的服务采用的生命周期模式依次为「瞬时\作用域\单例」。
由于每个服务都可以有多种实现，所以在进行服务注册时，可以为同一个服务注册多个不同的实现类。
虽然可以注册服务的多个实现类，但是GetService方法只能返回其中一个实现类的实例，也就是最后注册的实现类。
如果想要获取某个服务的所有实现，我们可以看这个示例：
public static classSample02 { //... public abstract class Base { } public class Account:Base, IAccount{} public class Message:Base, IMessage{} public class Tool:Base, ITool{} public static void Run() { // 创建服务集合 var serviceCollection = new ServiceCollection(); // 注册服务 serviceCollection.AddTransient<Base, Account>(); serviceCollection.AddScoped<Base, Message>(); serviceCollection.AddSingleton<Base, Tool>(); // 创建服务提供对象 var serviceProvider = serviceCollection.BuildServiceProvider(); // 获取服务集合 var services = serviceProvider.GetServices<Base>().ToList(); } }
示例中添加了一个 Base 抽象类，其它的类型都是 Base 的具体类。
这种抽象类和具体类的关系，类似接口与实现类的关系，所以也可以注册到依赖注入系统中。
使用GetServices 方法可以获取某个服务的类型集合，注意这个 Service 是复数形式。
示例中返回的是一个 Base 类集合，集合的元素就是已注册的 3 个具体类实例。
生命周期模式
通过前面的示例，我们可以发现，服务注册的方法有多个，每一个方法对应着不同的生命周期。
那么什么是生命周期呢？
简单来说，服务的生命周期代表着每一个服务实例的生存期。
为什么依赖注入系统中的服务实例要定义生命周期呢？
因为依赖注入系统，管理着整个应用的服务实例。
在我们开发应用的时候，肯定用到过单例。被设计为单例模式的对象，在整个应用的生命周期中，有且只有一个。
非单例模式的普通对象，都是随用随建，用完即丢。
既然依赖注入系统管理着整个应用的服务实例，那么不管是高贵的单例对象、还是没有人权普通对象，都是依赖注入系统中的一员。
于是，为了让依赖注入系统分辨出哪个对象属于哪种模式，就有了不同模式的生命周期。
前面我们说过，生命周期的模式有三种：瞬时、作用域和单例。
其中，瞬时和单例理解起来比较简单。
- 「瞬时，就是没有生存期。」
也就是说，每次从依赖注入系统中获取瞬时的服务实例时，都会创建一个全新的对象。
依赖注入系统中的服务容器不会保存它，也就是没有生存权的普通对象。
- 「单例，就是会一直存在，与应用同寿。」
也就是说，第一次从依赖注入系统中获取单例的服务实例时，才会创建一个全新的对象。
依赖注入系统中的服务容器会保存它，之后的每次使用都是直接从容器中获取它，也就是高贵的单例对象。
- 「作用域，理解起来没有那么直观，需要结合场景来说明。」
比如，在 ASP.NET 的应用中，每一个来自外部的请求，都可以理解为是一个请求作用域。不同的请求，就是不同的请求作用域。
在同一个请求作用域中，获取作用域模式的服务实例与单例模式的服务实例，具有同样的表现。
也就是说，第一次从依赖注入系统中获取服务实例时，才会创建一个全新的对象。
依赖注入系统会在服务容器中为该作用域开个单间，单独保存该对象。
当请求结束时，请求作用域会被销毁，单间自然也就没了，其中保存的对象也会随之销毁。
所以，在这种模式中生存的对象实例，都只作用于自己的域范围，不同的域不会互相干涉。
由此可见，服务一旦有了生命周期，那么依赖注入系统就可以根据需求，来保存和管理它们的实例。
原文地址：https://www.dongchuanmin.com/net/2009.html
