深入理解 ASP.NET Core 依赖注入

对于 ASP.NET Core 的依赖注入、控制反转以及 Autofac 等一直没有搞明白，但这篇文章让我从根本上了解了尤其是依赖注入的概念以及在 ASP.NET Core 中的应用，特推荐给需要的你。

一、什么是依赖注入（Denpendency Injection)

这也是个老生常谈的问题，到底依赖注入是什么？ 为什么要用它？ 初学者特别容易对控制反转IOC(Iversion of Control)，DI等概念搞晕。

1.1依赖

当一个类需要另一个类协作来完成工作的时候就产生了依赖。比如我们在AccountController这个控制器需要完成和用户相关的注册、登录等事情。其中的登录由EF结合Idnetity来完成，所以我们封装了一个EFLoginService。这里AccountController就有一个ILoginService的依赖。

这里有一个设计原则：依赖于抽象，而不是具体的实现。所以我们给EFLoginService定义了一个接口，抽象了LoginService的行为。

1.2 什么是注入

注入体现的是一个IOC（控制反转的思想）。在反转之前 ，我们先看看正转。

AccountController自己来实例化需要的依赖。

1 2 3 4 5

private ILoginService _loginService; public AccountController() {   _loginService = new EFLoginService() }

大师说，这样不好。你不应该自己创建它，而是应该由你的调用者给你。于是你通过构造函数让外界把这两个依赖传给你。

1 2 3 4 5

public  AccountController(ILoginService loginService) {   _loginService = loginService; }

把依赖的创建丢给其它人，自己只负责使用，其它人丢给你依赖的这个过程理解为注入。

1.3 为什么要反转？

为了在业务变化的时候尽少改动代码可能造成的问题。

比如我们现在要把从EF中去验证登录改为从Redis去读，于是我们加了一个 RedisLoginService。这个时候我们只需要在原来注入的地方改一下就可以了。

1 2 3 4 5

public  AccountController(ILoginService loginService) {   _loginService = loginService; }

// 用Redis来替换原来的EF登录
var controller = new AccountController(new RedisLoginService()); controller.Login(userName, password);

1.4 何为容器

上面我们在使用AccountController的时候，我们自己通过代码创建了一个ILoggingServce的实例。想象一下，一个系统中如果有100个这样的地方，我们是不是要在100个地方做这样的事情？ 控制是反转了，依赖的创建也移交到了外部。现在的问题是依赖太多，我们需要一个地方统一管理系统中所有的依赖，因此容器诞生了。

容器负责两件事情：

• 绑定服务与实例之间的关系

• 获取实例，并对实例进行管理（创建与销毁）

二、.NET Core DI

2.1 实例的注册

前面讲清楚DI和Ioc的关键概念之后，我们先来看看在控制台中对 .NET Core DI 的应用。在 .NET Core 中 DI 的核心分为两个组件：IServiceCollection 和 IServiceProvider。

• IServiceCollection 负责注册

• IServiceProvider 负责提供实例

通过默认的 ServiceCollection（在Microsoft.Extensions.DependencyInjection命名空间下）有三个方法：

1 2 3 4

var serviceCollection = new ServiceCollection()   .AddTransient()   .AddSingleton()   .AddScoped();

　　这三个方法都是将我们的实例注册进去，只不过实例的生命周期不一样。什么是生命周期我们下一节接着讲。

ServiceCollection的默认实现是提供一个ServiceDescriptor的List

1 2 3

public interface IServiceCollection : IList { }

　　我们上面的AddTransient、AddSignletone和Scoped方法是IServiceCollection的扩展方法， 都是往这个List里面添加ServiceDescriptor。

1 2 3 4 5 6 7 8 9 10 11

private static IServiceCollection Add(   IServiceCollection collection,   Type serviceType,   Type implementationType,   ServiceLifetime lifetime) {   var descriptor =   new ServiceDescriptor(serviceType, implementationType, lifetime);   collection.Add(descriptor);   return collection; }

2.2 实例的生命周期之单例

我们上面看到了，.NET Core DI 为我们提供的实例生命周其包括三种：

• Transient： 每一次 GetService 都会创建一个新的实例
• Scoped：  在同一个 Scope 内只初始化一个实例 ，可以理解为（ 每一个 request 级别只创建一个实例，同一个 http request会在一个 scope 内）
• Singleton ：整个应用程序生命周期以内只创建一个实例 

对应了Microsoft.Extensions.DependencyInjection.ServiceLifetime的三个枚举值

1 2 3 4 5 6

public enum ServiceLifetime {   Singleton,   Scoped,   Transient }

为了大家能够更好的理解这个生命周期的概念我们做一个测试：

定义一个最基本的 IOperation 里面有一个 OperationId 的属性，IOperationSingleton也是一样，只不过是另外一个接口。

1 2 3 4 5 6 7

public interface IOperation {         Guid OperationId { get; } } public interface IOperationSingleton : IOperation { } public interface IOperationTransient : IOperation{} public interface IOperationScoped : IOperation{}

我们的 Operation 实现很简单，可以在构造函数中传入一个Guid进行赋值，如果没有的话则自已New一个 Guid。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public class Operation :   IOperationSingleton,   IOperationTransient,   IOperationScoped {     private Guid _guid;       public Operation() {         _guid = Guid.NewGuid();     }       public Operation(Guid guid)     {         _guid = guid;     }       public Guid OperationId => _guid; }

在程序内我们可以多次调用ServiceProvider的GetService方法，获取到的都是同一个实例。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

var services = new ServiceCollection(); // 默认构造 services.AddSingleton(); // 自定义传入Guid空值 services.AddSingleton(   new Operation(Guid.Empty)); // 自定义传入一个New的Guid services.AddSingleton (   new Operation(Guid.NewGuid()));   var provider = services.BuildServiceProvider();   // 输出singletone1的Guid var singletone1 = provider.GetService(); Console.WriteLine($"signletone1: {singletone1.OperationId}");   // 输出singletone2的Guid var singletone2 = provider.GetService(); Console.WriteLine($"signletone2: {singletone2.OperationId}"); Console.WriteLine($"singletone1 == singletone2 ? : { singletone1 == singletone2 }");

我们对IOperationSingleton注册了三次，最后获取两次，大家要注意到我们获取到的始终都是我们最后一次注册的那个给了一个Guid的实例，前面的会被覆盖。

2.3 实例生命周期之Tranisent 

这次我们获取到的 IOperationTransient 为两个不同的实例。

2.4 实例生命周期之Scoped

.NET Core 的 IServiceProvider 提供 CreateScope 产生一个新的 ServiceProvider 范围，在这个范围下的 Scope 标注的实例将只会是同一个实例。换句话来说：用 Scope 注册的对象，在同一个 ServiceProvider 的 Scope下相当于单例。

同样我们先分别注册 IOperationScoped、IOperationTransient 和 IOperationSingletone 这三个实例，用对应的 Scoped、Transient、和 Singleton 生命周期。

1 2 3 4

var services = new ServiceCollection() .AddScoped() .AddTransient() .AddSingleton();

接下来我们用ServiceProvider.CreateScope方法创建一个Scope

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

var provider = services.BuildServiceProvider(); using (var scope1 = provider.CreateScope()) {     var p = scope1.ServiceProvider;       var scopeobj1 = p.GetService();     var transient1 = p.GetService();     var singleton1 = p.GetService();       var scopeobj2 = p.GetService();     var transient2 = p.GetService();     var singleton2 = p.GetService();       Console.WriteLine(         $"scope1: { scopeobj1.OperationId }," +         $"transient1: {transient1.OperationId}, " +         $"singleton1: {singleton1.OperationId}");       Console.WriteLine($"scope2: { scopeobj2.OperationId }, " +         $"transient2: {transient2.OperationId}, " +         $"singleton2: {singleton2.OperationId}"); }

接下来

scope1: 200d1e63-d024-4cd3-88c9-35fdf5c00956, 
transient1: fb35f570-713e-43fc-854c-972eed2fae52, 
singleton1: da6cf60f-670a-4a86-8fd6-01b635f74225

scope2: 200d1e63-d024-4cd3-88c9-35fdf5c00956, 
transient2: 2766a1ee-766f-4116-8a48-3e569de54259, 
singleton2: da6cf60f-670a-4a86-8fd6-01b635f74225

如果再创建一个新的Scope运行，

scope1: 29f127a7-baf5-4ab0-b264-fcced11d0729, 
transient1: 035d8bfc-c516-44a7-94a5-3720bd39ce57, 
singleton1: da6cf60f-670a-4a86-8fd6-01b635f74225

scope2: 29f127a7-baf5-4ab0-b264-fcced11d0729, 
transient2: 74c37151-6497-4223-b558-a4ffc1897d57, 
singleton2: da6cf60f-670a-4a86-8fd6-01b635f74225

大家注意到上面我们一共得到了 4个Transient实例，2个Scope实例，1个Singleton实例。

这有什么用？

如果在 Mvc 中用过 Autofac 的 InstancePerRequest 的同学就知道，有一些对象在一个请求跨越多个Action或者多个Service、Repository 的时候，比如最常用的 DBContext 它可以是一个实例。即能减少实例初始化的消耗，还能实现跨 Service 事务的功能。(注：在 ASP.NET Core 中所有用到 EF 的 Service 都需要注册成 Scoped )

而实现这种功能的方法就是在整个reqeust请求的生命周期以内共用了一个Scope。

三、DI在ASP.NET Core中的应用

3.1在Startup类中初始化

ASP.NET Core 可以在 Startup.cs 的 ConfigureService 中配置 DI，大家看到 IServiceCollection 这个参数应该就比较熟悉了。

1 2 3 4 5 6

public void ConfigureServices(IServiceCollection services) {     services.AddTransient,       EFLoginService>();     services.AddMvc(); )

ASP.NET Core 的一些组件已经提供了一些实例的绑定，像 AddMvc 就是 Mvc Middleware 在 IServiceCollection 上添加的扩展方法。

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public static IMvcBuilder AddMvc(this IServiceCollection services) {     if (services == null)     {         throw new ArgumentNullException(nameof(services));     }       var builder = services.AddMvcCore();       builder.AddApiExplorer();     builder.AddAuthorization();     AddDefaultFrameworkParts(builder.PartManager);     ... }

3.2 Controller中使用

一般可以通过构造函数或者属性来实现注入，但是官方推荐是通过构造函数。这也是所谓的显式依赖。

1 2 3 4 5 6

private ILoginService _loginService; public AccountController(   ILoginService loginService) {   _loginService = loginService; }

　　我们只要在控制器的构造函数里面写了这个参数，ServiceProvider 就会帮我们注入进来。这一步是在 Mvc 初始化控制器的时候完成的，我们后面在介绍到Mvc的时候会往细里讲。

 

3.3 View中使用

在 View 中需要用 @inject 再声明一下，起一个别名。

1 2 3 4 5 6 7 8 9 10

@using MilkStone.Services; @model MilkStone.Models.AccountViewModel.LoginViewModel @inject ILoginService  loginService "http://www.w3.org/1999/xhtml">   @loginService.GetUserName()

3.4 通过HttpContext来获取实例

HttpContext 下有一个 RequestedService 同样可以用来获取实例对象，不过这种方法一般不推荐。同时要注意GetService<>这是个范型方法，默认如果没有添加Microsoft.Extension.DependencyInjection的using，是不用调用这个方法的。

1	HttpContext.RequestServices.GetService>();

四、如何替换其它的Ioc容器

Autofac 也是不错的选择，但我们首先要搞清楚为什么要替换掉默认的 DI 容器？，替换之后有什么影响？.NET Core 默认的实现对于一些小型的项目完全够用，甚至大型项目麻烦点也能用，但是会有些麻烦，原因在于只提供了最基本的 AddXXXX 方法来绑定实例关系，需要一个一个的添加。如果项目可能要添加好几百行这样的方法就需要寻找其他方法了。

熟悉 Autofac 的同学可能对下面这样的代码有印象。

1 2 3

builder.RegisterGeneric(typeof(LoggingBehavior<,>)).As(typeof(IPipelineBehavior<,>));    builder.RegisterGeneric(typeof(ValidatorBehavior<,>)).As(typeof(IPipelineBehavior<,>));

这会给我们的初始化带来一些便利性，我们来看看如何替换 Autofac 到 ASP.NET Core。我们只需要把 Startup 类里面 ConfigureService 的返回值从 void 改为 IServiceProvider 即可。而返回的则是一个 AutoServiceProvider。

1 2 3 4 5 6 7 8 9 10 11 12

public IServiceProvider ConfigureServices(   IServiceCollection services){     services.AddMvc();     // Add other framework services       // Add Autofac     var containerBuilder = new ContainerBuilder();     containerBuilder.RegisterModule();     containerBuilder.Populate(services);     var container = containerBuilder.Build();     return new AutofacServiceProvider(container); }

4.1 有何变化 

其中很大的一个变化在于，Autofac 原来的一个生命周期 InstancePerRequest，将不再有效。正如我们前面所说的，整个 request 的生命周期被 ASP.NET Core 管理了，所以 Autofac 的这个将不再有效。我们可以使用 InstancePerLifetimeScope ，同样是有用的，对应了我们 ASP.NET Core DI 里面的 Scoped。 

原文链接：https://www.cnblogs.com/jesse2013/p/di-in-aspnetcore.html