这篇文章是 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 class Sample02
{//...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 的应用中,每一个来自外部的请求,都可以理解为是一个请求作用域。不同的请求,就是不同的请求作用域。
在同一个请求作用域中,获取作用域模式的服务实例与单例模式的服务实例,具有同样的表现。
也就是说,第一次从依赖注入系统中获取服务实例时,才会创建一个全新的对象。
依赖注入系统会在服务容器中为该作用域开个单间,单独保存该对象。
当请求结束时,请求作用域会被销毁,单间自然也就没了,其中保存的对象也会随之销毁。
所以,在这种模式中生存的对象实例,都只作用于自己的域范围,不同的域不会互相干涉。
由此可见,服务一旦有了生命周期,那么依赖注入系统就可以根据需求,来保存和管理它们的实例。
更多精彩内容,请关注我▼▼
如果喜欢我的文章,那么
在看和转发是对我最大的支持!
(戳下面蓝字阅读)
ASP.NET 6 中间件系列
推荐关注微信公众号:码侠江湖
觉得不错,点个在看再走哟