.NET8 依赖注入_Asp.net

依赖注入（dependency injection，简称di）是一种设计模式，用于解耦组件（服务）之间的依赖关系。它通过将依赖关系的创建和管理交给外部容器来实现，而不是在组件（服务）内部直接创建依赖对象。

咱就是通过 iservicecollection 和 iserviceprovider 来实现的，他们直接被收入到了runtime libraries，在整个.net平台下通用！

1.1 servicecollection

iservicecollection 本质是一个 servicedescriptor 而 servicedescriptor 则是用于描述服务类型，实现和生命周期

public interface iservicecollection : 
    ilist<servicedescriptor>,
    icollection<servicedescriptor>,
    ienumerable<servicedescriptor>,
    ienumerable;

官方提供一些列拓展帮助我们向服务容器中添加服务描述，具体在 servicecollectionserviceextensions

builder.services.addtransient<studentservice>();
builder.services.addkeyedtransient<istudentrepository, studentrepository>("a");
builder.services.addkeyedtransient<istudentrepository, studentrepository2>("b");
builder.services.addtransient<transientservice>();
builder.services.addscoped<scopeservice>();
builder.services.addsingleton<singletonservice>();

1.2 serviceprovider

iserviceprovider 定义了一个方法 getservice，帮助我们通过给定的服务类型，获取其服务实例

public interface iserviceprovider
{
  object? getservice(type servicetype);
}

下面是 getservice 的默认实现（如果不给定engine scope，则默认是root）

public object? getservice(type servicetype) => getservice(serviceidentifier.fromservicetype(servicetype), root);

也就是

internal object? getservice(serviceidentifier serviceidentifier, serviceproviderenginescope serviceproviderenginescope)
{
    if (_disposed)
    {
        throwhelper.throwobjectdisposedexception();
    }
    // 获取服务标识符对应的服务访问器
    serviceaccessor serviceaccessor = _serviceaccessors.getoradd(serviceidentifier, _createserviceaccessor);
    // 执行解析时的hock
    onresolve(serviceaccessor.callsite, serviceproviderenginescope);
    dependencyinjectioneventsource.log.serviceresolved(this, serviceidentifier.servicetype);
    // 通过服务访问器提供的解析服务，得到服务实例
    object? result = serviceaccessor.realizedservice?.invoke(serviceproviderenginescope);
    system.diagnostics.debug.assert(result is null || callsitefactory.isservice(serviceidentifier));
    return result;
}

其中，服务标识符 serviceidentifier 其实就是包了一下服务类型，和服务key（为了.net8的键化服务）

internal readonly struct serviceidentifier : iequatable<serviceidentifier>
{
    public object? servicekey { get; }
    public type servicetype { get; }
}

显而易见的，我们的服务解析是由 serviceaccessor.realizedservice 提供，而创建服务访问器 serviceaccessor 只有一个实现 createserviceaccessor

private serviceaccessor createserviceaccessor(serviceidentifier serviceidentifier)
{
    // 通过 callsitefactory 获取服务的调用点（callsite），这是服务解析的一个表示形式。
    servicecallsite? callsite = callsitefactory.getcallsite(serviceidentifier, new callsitechain());
    // 如果调用站点不为空，则继续构建服务访问器。
    if (callsite != null)
    {
        dependencyinjectioneventsource.log.callsitebuilt(this, serviceidentifier.servicetype, callsite);
        // 触发创建调用站点的相关事件。
        oncreate(callsite);
        // 如果调用站点的缓存位置是根（root），即表示这是一个单例服务。
        if (callsite.cache.location == callsiteresultcachelocation.root)
        {
            // 直接拿缓存内容
            object? value = callsiteruntimeresolver.instance.resolve(callsite, root);
            return new serviceaccessor { callsite = callsite, realizedservice = scope => value };
        }
        // 通过引擎解析
        func<serviceproviderenginescope, object?> realizedservice = _engine.realizeservice(callsite);
        return new serviceaccessor { callsite = callsite, realizedservice = realizedservice };
    }
    // 如果调用点为空，则它的实现服务函数总是返回 null。
    return new serviceaccessor { callsite = callsite, realizedservice = _ => null };
}

1.2.1 serviceproviderengine

serviceproviderengine 是服务商解析服务的执行引擎，它在服务商被初始化时建立。有两种引擎，分别是动态引擎和运行时引擎，在 netframework || netstandard2_0 默认使用动态引擎。

        private serviceproviderengine getengine()
        {
            serviceproviderengine engine;
#if netframework || netstandard2_0
            engine = createdynamicengine();
#else
            if (runtimefeature.isdynamiccodecompiled && !disabledynamicengine)
            {
                engine = createdynamicengine();
            }
            else
            {
                // don't try to compile expressions/il if they are going to get interpreted
                engine = runtimeserviceproviderengine.instance;
            }
#endif
            return engine;
            [unconditionalsuppressmessage("aotanalysis", "il3050:requiresdynamiccode",
                justification = "createdynamicengine won't be called when using nativeaot.")] // see also https://github.com/dotnet/linker/issues/2715
            serviceproviderengine createdynamicengine() => new dynamicserviceproviderengine(this);
        }

由于.net aot技术与dynamic技术冲突，因此aot下只能使用运行时引擎，但动态引擎在大多情况下仍然是默认的。

动态引擎使用了emit技术，这是一个动态编译技术，而aot的所有代码都需要在部署前编译好，因此运行时无法生成新的代码。那运行时引擎主要使用反射，目标是在不牺牲太多性能的情况下，提供一个在aot环境中可行的解决方案。

我们展开动态引擎来看看它是如何解析服务的。

public override func<serviceproviderenginescope, object?> realizeservice(servicecallsite callsite)
{
    // 定义一个局部变量来跟踪委托被调用的次数
    int callcount = 0;
    return scope =>
    {
        // 当委托被调用时，先使用callsiteruntimeresolver.instance.resolve方法来解析服务。这是一个同步操作，确保在编译优化之前，服务可以被正常解析。
        var result = callsiteruntimeresolver.instance.resolve(callsite, scope);
        // 委托第二次被调用，通过unsafequeueuserworkitem在后台线程上启动编译优化
        if (interlocked.increment(ref callcount) == 2)
        {
            // 将一个工作项排队到线程池，但不捕获当前的执行上下文。
            _ = threadpool.unsafequeueuserworkitem(_ =>
            {
                try
                {
                    // 用编译优化后的委托替换当前的服务访问器，主要用到emit/expression技术
                    _serviceprovider.replaceserviceaccessor(callsite, base.realizeservice(callsite));
                }
                catch (exception ex)
                {
                    dependencyinjectioneventsource.log.servicerealizationfailed(ex, _serviceprovider.gethashcode());
                    debug.fail($"we should never get exceptions from the background compilation.{environment.newline}{ex}");
                }
            },
            null);
        }
        return result;
    };
}

这个实现的关键思想是，第一次解析服务时使用一个简单的运行时解析器，这样可以快速返回服务实例。然后，当服务再被解析，它会在后台线程上启动一个编译过程，生成一个更高效的服务解析委托。一旦编译完成，新的委托会替换掉原来的委托，以后的服务解析将使用这个新的、更高效的委托。这种方法可以在不影响应用程序启动时间的情况下，逐渐优化服务解析的性能。

1.2.2 serviceproviderenginescope

serviceproviderenginescope 闪亮登场，他是我们服务商的代言人，从定义不难看出他对外提供了服务商所具备的一切能力

internal sealed class serviceproviderenginescope : iservicescope, iserviceprovider, ikeyedserviceprovider, 			iasyncdisposable, iservicescopefactory
{
    // this scope中所有实现idisposable or iasyncdisposable的服务
    private list<object>? _disposables;
    // 解析过的服务缓存（其实就是scope生命周期的服务缓存，singleton生命周期的服务缓存都直接挂在调用点上了）
    internal dictionary<servicecachekey, object?> resolvedservices { get; }
    // 实锤服务商代言人
    public iserviceprovider serviceprovider => this;
    // 没错啦，通过root scope我们又能继续创建无数个scope，他们彼此独立
    public iservicescope createscope() => rootprovider.createscope();
}

我们来观察他获取服务的逻辑，可以发现他就是很朴实无华的用着我们根服务商 serviceprovider，去解析服务，那 engine scope 呢，就是 this。现在我们已经隐约可以知道engine scope，就是为了满足scope生命周期而生。而 resolvedservices 中存的呢，就是该scope中的所有scope生命周期服务实例啦，在这个scope中他们是唯一的。

public object? getservice(type servicetype)
{
    if (_disposed)
    {
        throwhelper.throwobjectdisposedexception();
    }
    return rootprovider.getservice(serviceidentifier.fromservicetype(servicetype), this);
}

再来看另一个核心的方法：capturedisposable，实现disposable的服务会被添加到 _disposables。

internal object? capturedisposable(object? service)
{
    // 如果服务没有实现 idisposable or iasyncdisposable，那么不需要捕获，直接原路返回
    if (referenceequals(this, service) || !(service is idisposable || service is iasyncdisposable))
    {
        return service;
    }
    bool disposed = false;
    lock (sync)
    {
        if (_disposed) // 如果scope已经销毁则进入销毁流程
        {
            disposed = true;
        }
        else
        {
            _disposables ??= new list<object>();
            _disposables.add(service);
        }
    }
    // don't run customer code under the lock
    if (disposed) // 这表示我们在试图捕获可销毁服务时，scope就已经被销毁
    {
        if (service is idisposable disposable)
        {
            disposable.dispose();
        }
        else
        {
            // sync over async, for the rare case that an object only implements iasyncdisposable and may end up starving the thread pool.
            object? localservice = service; // copy to avoid closure on other paths
            task.run(() => ((iasyncdisposable)localservice).disposeasync().astask()).getawaiter().getresult();
        }
        // 这种case会抛出一个objectdisposedexception
        throwhelper.throwobjectdisposedexception();
    }
    return service;
}

在engine scope销毁时，其作用域中所有scope生命周期且实现了disposable的服务（其实就是_disposable）呢，也会被一同的销毁。

public valuetask disposeasync()
{
    list<object>? todispose = begindispose(); // 获取_disposable
    if (todispose != null)
    {
        // 从后往前，依次销毁服务
    }
}

那么有同学可能就要问了：单例实例既然不存在root scope中，而是单独丢到了调用点上，那他是咋销毁的？压根没看到啊，那不得泄露了？

其实呀，同学们并不用担心这个问题。首先，单例服务的实例确实是缓存在调用点上，但 disable 服务仍然会被 scope 捕获呀（在下文会详细介绍）。在 begindispose 中的，我们会去判断，如果是 singleton case，且root scope 没有被销毁过，我们会主动去销毁喔~

if (isrootscope && !rootprovider.isdisposed()) rootprovider.dispose();

1.3 servicecallsite

servicecallsite 的主要职责是封装服务解析的逻辑，它可以代表一个构造函数调用、属性注入、工厂方法调用等。di系统使用这个抽象来表示服务的各种解析策略，并且可以通过它来生成服务实例。

internal abstract class servicecallsite
{
    protected servicecallsite(resultcache cache)
	 {
	     cache = cache;
	 }
    public abstract type servicetype { get; }
	 public abstract type? implementationtype { get; }
	 public abstract callsitekind kind { get; }
	 public resultcache cache { get; }
	 public object? value { get; set; }
	 public object? key { get; set; }
	 public bool capturedisposable => implementationtype == null ||
    	typeof(idisposable).isassignablefrom(implementationtype) ||
    	typeof(iasyncdisposable).isassignablefrom(implementationtype);
}

1.3.1 resultcache

其中 resultcache 定义了我们如何缓存解析后的结果

public callsiteresultcachelocation location { get; set; } // 缓存位置
public servicecachekey key { get; set; } // 服务key（键化服务用的）

callsiteresultcachelocation 是一个枚举，定义了几个值

root：表示服务实例应该在根级别的 iserviceprovider 中缓存。这通常意味着服务实例是单例的（singleton），在整个应用程序的生命周期内只会创建一次，并且在所有请求中共享。
scope：表示服务实例应该在当前作用域（scope）中缓存。对于作用域服务（scoped），实例会在每个作用域中创建一次，并在该作用域内的所有请求中共享。
dispose：尽管这个名称可能会让人误解，但在 resultcache 的上下文中，dispose 表示着服务是瞬态的（每次请求都创建新实例）。
none：表示没有缓存服务实例。

servicecachekey 结构体就是包了一下服务标识符和一个slot，用于适配多实现的

internal readonly struct servicecachekey : iequatable<servicecachekey>
{
    public serviceidentifier serviceidentifier { get; }
    public int slot { get; } // 那最后一个实现的slot是0
}

1.3.2 callsitefactory.getcallsite

那我们来看看调用点是怎么创建的吧，其实上面已经出现过一次了：

private servicecallsite? createcallsite(serviceidentifier serviceidentifier, callsitechain callsitechain)
{
    if (!_stackguard.tryenteroncurrentstack()) // 防止栈溢出
    {
        return _stackguard.runonemptystack(createcallsite, serviceidentifier, callsitechain);
    }
    // 获取服务标识符对应的锁，以确保在创建调用点时的线程安全。
    // 是为了保证并行解析下的调用点也只会被创建一次，例如：
    // c -> d -> a
    // e -> d -> a
    var callsitelock = _callsitelocks.getoradd(serviceidentifier, static _ => new object());
    lock (callsitelock)
    {
        // 检查当前服务标识符是否会导致循环依赖
        callsitechain.checkcirculardependency(serviceidentifier);
        // 首先尝试创建精确匹配的服务调用站点，如果失败，则尝试创建开放泛型服务调用站点，如果还是失败，则尝试创建枚举服务调用站点。如果所有尝试都失败了，callsite将为null。
        servicecallsite? callsite = trycreateexact(serviceidentifier, callsitechain) ??
                                   trycreateopengeneric(serviceidentifier, callsitechain) ??
                                   trycreateenumerable(serviceidentifier, callsitechain);
        return callsite;
    }
}

那服务点的创建过程我就简单概述一下啦

查找调用点缓存，存在就直接返回啦
服务标识符会被转成服务描述符 servicedescriptor （key化服务不指定key默认取last）
计算servicecallsite，依次是：trycreateexact
计算 resultcache

如果已经有实现实例了，则返回 constantcallsite：表示直接返回已经创建的实例的调用点。

如果有实现工厂，则返回 factorycallsite：表示通过工厂方法创建服务实例的调用点。

如果有实现类型，则返回 constructorcallsite：表示通过构造函数创建服务实例的调用点。
trycreateopengeneric
根据泛型定义获取服务描述符 servicedescriptor

计算 resultcache

使用服务标识符中的具体泛型参数来构造实现的闭合类型

aot兼容性测试（因为不能保证值类型泛型的代码已经生成）

如果成功闭合，则返回 constructorcallsite：表示通过构造函数创建服务实例的调用点。
trycreateenumerable
确定类型是 ienumerable<t>

aot兼容性测试（因为不能保证值类型数组的代码已经生成）

如果 t 不是泛型类型，并且可以找到对应的服务描述符集合，则循环 trycreateexact

否则，方向循环 trycreateexact，然后方向循环 trycreateopengeneric

1.4 callsitevisitor

好了，有了上面的了解我们可以开始探索服务解析的内幕了。服务解析说白了就是引擎围着 callsitevisitor 转圈圈，所谓的解析服务，其实就是访问调用点了。

protected virtual tresult visitcallsite(servicecallsite callsite, targument argument)
{
    if (!_stackguard.tryenteroncurrentstack()) // 一些校验，分栈啥的
    {
        return _stackguard.runonemptystack(visitcallsite, callsite, argument);
    }
    switch (callsite.cache.location)
    {
        case callsiteresultcachelocation.root: // 单例
            return visitrootcache(callsite, argument);
        case callsiteresultcachelocation.scope: // 作用域
            return visitscopecache(callsite, argument);
        case callsiteresultcachelocation.dispose: // 瞬态
            return visitdisposecache(callsite, argument);
        case callsiteresultcachelocation.none: // 不缓存（constantcallsite）
            return visitnocache(callsite, argument);
        default:
            throw new argumentoutofrangeexception();
    }
}

为了方便展示，我们这里的解析器都拿运行时来说，因为内部是反射，而emit、expression实在是难以观看。

1.4.1 visitrootcache

那我们来看看单例的情况下，是如何访问的：

protected override object? visitrootcache(servicecallsite callsite, runtimeresolvercontext context)
{
    if (callsite.value is object value)
    {
        // value already calculated, return it directly
        return value;
    }
    var locktype = runtimeresolverlock.root;
    // 单例都是直接放根作用域的
    serviceproviderenginescope serviceproviderengine = context.scope.rootprovider.root;
    lock (callsite)
    {
        // 这里搞了个双检锁来确保在多线程环境中，同一时间只有一个线程可以执行接下来的代码块。
        // lock the callsite and check if another thread already cached the value
        if (callsite.value is object callsitevalue)
        {
            return callsitevalue;
        }
        object? resolved = visitcallsitemain(callsite, new runtimeresolvercontext
        {
            scope = serviceproviderengine,
            acquiredlocks = context.acquiredlocks | locktype
        });
        // 捕获可销毁的服务
        serviceproviderengine.capturedisposable(resolved);
        // 缓存解析结果到调用点上
        callsite.value = resolved;
        return resolved;
    }
}

好，可以看到真正解析调用点的主角出来了 visitcallsitemain，那这里的 callsitekind 上面计算 servicecallsite 时呢已经讲的很清楚啦，咱对号入座就行了

protected virtual tresult visitcallsitemain(servicecallsite callsite, targument argument)
{
    switch (callsite.kind)
    {
        case callsitekind.factory:
            return visitfactory((factorycallsite)callsite, argument);
        case  callsitekind.ienumerable:
            return visitienumerable((ienumerablecallsite)callsite, argument);
        case callsitekind.constructor:
            return visitconstructor((constructorcallsite)callsite, argument);
        case callsitekind.constant:
            return visitconstant((constantcallsite)callsite, argument);
        case callsitekind.serviceprovider:
            return visitserviceprovider((serviceprovidercallsite)callsite, argument);
        default:
            throw new notsupportedexception(sr.format(sr.callsitetypenotsupported, callsite.gettype()));
    }
}

我们就看看最经典的通过构造函数创建服务实例的调用点 constructorcallsite，很显然就是new嘛，只不过可能构造中依赖其它服务，那就递归创建呗。easy，其它几种太简单了大家自己去看看吧。

protected override object visitconstructor(constructorcallsite constructorcallsite, runtimeresolvercontext context)
{
    object?[] parametervalues;
    if (constructorcallsite.parametercallsites.length == 0)
    {
        parametervalues = array.empty<object>();
    }
    else
    {
        parametervalues = new object?[constructorcallsite.parametercallsites.length];
        for (int index = 0; index < parametervalues.length; index++)
        {
            // 递归构建依赖的服务
            parametervalues[index] = visitcallsite(constructorcallsite.parametercallsites[index], context);
        }
    }
    // new (xxx)
    return constructorcallsite.constructorinfo.invoke(bindingflags.donotwrapexceptions, binder: null, parameters: parametervalues, culture: null);
}

1.4.2 visitscopecache

在访问单例缓存的时候呢，仅仅通过了一个double check lock就搞定了，因为人家全局的嘛，咱再来看看访问作用域缓存，会不会有什么不一样

protected override object? visitscopecache(servicecallsite callsite, runtimeresolvercontext context)
{
    // check if we are in the situation where scoped service was promoted to singleton
    // and we need to lock the root
    return context.scope.isrootscope ?
        visitrootcache(callsite, context) :
        visitcache(callsite, context, context.scope, runtimeresolverlock.scope);
}

哈哈，它果然很不一般啊，上来就来检查我们是否是 root scope。如果是这种case呢，则走 visitrootcache。但是奇怪啊，为什么访问 scope cache，所在 engine scope 能是 root scope？

还记得 serviceprovider 获取的服务实例的核心方法吗？engine scope 他是传进来的，如果我们给一个 root scope，自然就出现的这种case，只是这种 case 特别罕见。

internal object? getservice(serviceidentifier serviceidentifier, serviceproviderenginescope serviceproviderenginescope)

visitcache 的同步模型写的实在是酷，我们看 runtimeresolverlock 的枚举就两个：scope = 1 和 root = 2

acquiredlocks=scope时
那 acquiredlocks&false==0 显然成立，申请锁，也就是尝试独占改作用域的resolvedservices
申请成功进入同步块，重新计算acquiredlocks|true=1
如此，在该engine scope 中这条链路上的调用点都被占有，直到结束
acquiredlocks=root 时
- 那显然 engine scope 也应该是 root scope，那么走 visitrootcache case
- 在 visitrootcache 通过dcl锁住 root scope 上链路涉及的服务点，直至结束

至此我们应该不难看出这个设计的精妙之处，即在非 root scope（scope生命周期）中，scope之间是互相隔离的，没有必要像 root scope（singleton生命周期）那样，在所有scope中独占服务点。

private object? visitcache(servicecallsite callsite, runtimeresolvercontext context, serviceproviderenginescope serviceproviderengine
{
    bool locktaken = false;
    object sync = serviceproviderengine.sync;
    dictionary<servicecachekey, object?> resolvedservices = serviceproviderengine.resolvedservices;
    if ((context.acquiredlocks & locktype) == 0)
    {
        monitor.enter(sync, ref locktaken);
    }
    try
    {
        // note: this method has already taken lock by the caller for resolution and access synchronization.
        // for scoped: takes a dictionary as both a resolution lock and a dictionary access lock.
        if (resolvedservices.trygetvalue(callsite.cache.key, out object? resolved))
        {
            return resolved;
        }
        // scope服务的解析结果是放在engine scope的resolvedservices上的，而非调用点
        resolved = visitcallsitemain(callsite, new runtimeresolvercontext
        {
            scope = serviceproviderengine,
            acquiredlocks = context.acquiredlocks | locktype
        });
        serviceproviderengine.capturedisposable(resolved);
        resolvedservices.add(callsite.cache.key, resolved);
        return resolved;
    }
    finally
    {
        if (locktaken)
        {
            monitor.exit(sync);
        }
    }
}

1.4.3 visitdisposecache

我们看最后一个，也就是 transient case

protected override object? visitdisposecache(servicecallsite transientcallsite, runtimeresolvercontext context)
{
    return context.scope.capturedisposable(visitcallsitemain(transientcallsite, context));
}

异常的简单，我们沿用了scope的设计，但是我们没有进行任何缓存行为。即，每次都去访问调用点。

到此这篇关于.net8 依赖注入的文章就介绍到这了,更多相关.net8 依赖注入内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！