asp.net core 依赖注入实现全过程粗略剖析（2）

接着上篇目前也算是交代清楚了相关的类。那么框架具体是如何来实例化的呢？整个的流程是怎么样的。

我们参考源码中的Test文件夹来看看：

var collection = new ServiceCollection();

collection.AddTransient<DependOnNonexistentService>();

var provider = CreateServiceProvider(collection);

protected override IServiceProvider CreateServiceProvider(IServiceCollection collection) => collection.BuildServiceProvider();

public static ServiceProvider BuildServiceProvider(this IServiceCollection services)

{

    return BuildServiceProvider(services, ServiceProviderOptions.Default);

}

public class ServiceProviderOptions

{

    // Avoid allocating objects in the default case

    internal static readonly ServiceProviderOptions Default = new ServiceProviderOptions();

    /// <summary>

    /// <c>true</c> to perform check verifying that scoped services never gets resolved from root provider; otherwise <c>false</c>.

    /// </summary>

    public bool ValidateScopes { get; set; }

    internal ServiceProviderMode Mode { get; set; } = ServiceProviderMode.Dynamic;

}

internal enum ServiceProviderMode

{

    Dynamic,

    Runtime,

    Expressions,

    ILEmit

}

public static ServiceProvider BuildServiceProvider(this IServiceCollection services, ServiceProviderOptions options)

{

    if (services == null)

    {

        throw new ArgumentNullException(nameof(services));

    }

    if (options == null)

    {

        throw new ArgumentNullException(nameof(options));

    }

    return new ServiceProvider(services, options);

}

internal ServiceProvider(IEnumerable<ServiceDescriptor> serviceDescriptors, ServiceProviderOptions options)

{

    IServiceProviderEngineCallback callback = null;

    if (options.ValidateScopes)

    {

        callback = this;

        _callSiteValidator = new CallSiteValidator();

    }

    switch (options.Mode)

    {

        case ServiceProviderMode.Dynamic:

            _engine = new DynamicServiceProviderEngine(serviceDescriptors, callback);

            break;

        case ServiceProviderMode.Runtime:

            _engine = new RuntimeServiceProviderEngine(serviceDescriptors, callback);

            break;

#if IL_EMIT

        case ServiceProviderMode.ILEmit:

            _engine = new ILEmitServiceProviderEngine(serviceDescriptors, callback);

            break;

#endif

        case ServiceProviderMode.Expressions:

            _engine = new ExpressionsServiceProviderEngine(serviceDescriptors, callback);

            break;

        default:

            throw new NotSupportedException(nameof(options.Mode));

    }

}

如上所示，就是注入服务，实例化服务的整个过程了。我们主要是根据IServiceCollection的扩展方法BuilServiceProvider调用ServiceProvider类，进而实例化相关服务。

除去这种方式实现ServiceProvider外，默认asp.net core框架中还有一个DefaultServiceProviderFactory。不过这个工厂类最后也是调用IServiceCollection接口的拓展方法--BuildServiceProvider来创建ServiceProvider类。

总结：
IServiceCollection接口的拓展方法Addxxx 收集需要注入的服务，服务实现类型，服务的生命周期。这些就是在ServiceDescriptor中获取到的，也是该类的属性对象。这个也是IServiceCollection继承自IList<ServiceDescriptor>的解释所在。随后再获取ServiceProviderOptions枚举对象，选择实现实例化的类型，比如反射等。最后就是调用BuildServiceProvider来生成ServiceProvider了。ServiceProvider根据选择之前的选择及配置，实例化服务。

除去最后使用反射等来实例化服务之外，可以看出asp.net core的DI框架的设计思路是这样的：
将需要服务对象抽象化，首先，一个服务要进行DI，需要知道的是服务对象，实例对象，服务生命周期。将这三点抽象成一个ServiceDescriptor服务描述符对象。
由于需要DI的服务有很多，因此抽象出来一个容器来存储每个服务的三大对象（我们只叙述重要，常用的三个对象），也就是我们上面抽象出来的描述符对象。这个容器我们使用ServiceCollection来表示，它继承自IServiceCollection,而IServiceCollection其实就是IList<ServiceDescriptor>的集合，代表着众多的注入服务。服务的实例化我们抽象出来一个类：ServiceProvider，它实现一个接口，该接口只有一个方法GetService，表示获取指定服务的实例。
而我们将服务的实例化放在了该类的构造函数中，同时给它传入一个ServiceDescriptor集合对象，这个对象就包裹着需要注入服务的详细信息。随后使用指定的方式（在这里其实又抽象出来了一个配置类来指定实例化服务的方式）来实例化服务。

因此，ServiceCollection提供增删功能，这是对于ServiceDescriptor来存储的，ServiceDescriptor则是需要注入的服务的描述信息的抽象。ServiceProvider则是根据传入的配置类以及服务描述信息集合来实例化指定服务。

整个的设计思路其实就是一个抽象化的过程。这在设计中很有借鉴价值。

巴特西

asp.net core 依赖注入实现全过程粗略剖析（2）

最新文章

热门文章