[Abp vNext 源码分析] - 1. 框架启动流程分析

一、简要说明

本篇文章主要剖析与讲解 abp vnext 在 web api 项目下的启动流程，让大家了解整个 abp vnext 框架是如何运作的。总的来说 ，abp vnext 比起 abp 框架更加精简。因为在 vnext 版本当中，原来归属于 abp 库的许多内置的基本组件 (组织单元、拦截器等) 被拆分成了单独的模块，这样我们来看它整个启动流程就更加地直观清晰。

二、源码分析

要分析其源码，我这里是从他官方的 demo 模板入手的，你可以在 上构建你自己的模板项目。工具上我使用的是 jetbrains 家的 rider，配置好符号服务器(external symbols server)，我们就能够直接调试其底层源码。(因为 abp vnext 项目使用了 source link)

2.1 startup 文件的入口点

这里我选择的项目是 web api，直接来到其 startup.cs 文件，我们就可以看到在 startup 类当中的 configure() 与 configureservice() 方法内部我们注入并启用了 abp vnext 框架。

public class startup
{
    public iserviceprovider configureservices(iservicecollection services)
    {
        // 注入 abp 相关的服务。
        services.addapplication<demoappmodule>(options =>
                                               {
                                                   options.useautofac();
                                               });
        
        // 接管自带的 ioc container。
        return services.buildserviceproviderfromfactory();
    }

    public void configure(iapplicationbuilder app, ihostingenvironment env, iloggerfactory loggerfactory)
    {
        // 配置 asp.net core mvc 相关参数。
        app.initializeapplication();
    }
}

在上面我们可以看到，abp vnext 在注入服务的时候支持传入一个 action<abpapplicationcreationoptions> 委托。上述代码中，这个委托内部使用了 useautofac() 将 autofac 的容器注入到了 ms ioc 当中，关于这块代码下文会着重讲解。

2.2 abp 服务注册

在上一节看到的服务注册代码，是通过扩展 iservicecollection 接口编写的一个扩展方法实现的，在方法内部是通过 abpapplicationfactory 静态工厂来创建一个 abpapplicationbase 实例。

public static class servicecollectionapplicationextensions
{
    public static iabpapplicationwithexternalserviceprovider addapplication<tstartupmodule>(
        [notnull] this iservicecollection services, 
        [canbenull] action<abpapplicationcreationoptions> optionsaction = null)
        where tstartupmodule : iabpmodule
    {
        return abpapplicationfactory.create<tstartupmodule>(services, optionsaction);
    }
    
    // ... 其他代码
}

在这个方法当中，通过名字 withexternalserviceprovider 我们就知道，这个 applictaion 是依赖于外部的 iserviceprovider 实例。

提示：

它继承的 abpapplicationbase 基类还拥有另外一个实现，即 abpapplicationwithinternalserviceprovider 类型，该类型一般 用于控制台程序，它会在 abp vnext 框架内自行构建一个 iserviceprovider 对象。

我们回到之前的代码，在这个 abpapplicationwithexternalserviceprovider 类型内部的构造方法很简单，只是通过 iservicecollection 对象把自己注入到了服务集合当中。

internal class abpapplicationwithexternalserviceprovider : abpapplicationbase, iabpapplicationwithexternalserviceprovider
{
    public abpapplicationwithexternalserviceprovider(
        [notnull] type startupmoduletype, 
        [notnull] iservicecollection services, 
        [canbenull] action<abpapplicationcreationoptions> optionsaction
        ) : base(
            startupmoduletype, 
            services, 
            optionsaction)
    {
        // 注入自己到 ioc 当中。
        services.addsingleton<iabpapplicationwithexternalserviceprovider>(this);
    }

    // 执行框架初始化操作，主要工作是加载模块并执行其初始化方法。
    public void initialize(iserviceprovider serviceprovider)
    {
        check.notnull(serviceprovider, nameof(serviceprovider));

        setserviceprovider(serviceprovider);

        initializemodules();
    }
}

重点代码在于它的基类构造函数，在基类构造函数当中 abp vnext 注入了诸多 asp.net core 需要的日志服务、本地化服务等。并且它也抽象出了一个 imoduleloader，用于辅助我们加载模块。

internal abpapplicationbase(
    [notnull] type startupmoduletype,
    [notnull] iservicecollection services,
    [canbenull] action<abpapplicationcreationoptions> optionsaction)
{
    check.notnull(startupmoduletype, nameof(startupmoduletype));
    check.notnull(services, nameof(services));

    // 设置启动模块。
    startupmoduletype = startupmoduletype;
    services = services;

    // 添加一个空的对象访问器，该访问器的值会在初始化的时候被赋值。
    services.tryaddobjectaccessor<iserviceprovider>();

    // 调用用户传入的配置委托。
    var options = new abpapplicationcreationoptions(services);
    optionsaction?.invoke(options);

    // 注册自己。
    services.addsingleton<iabpapplication>(this);
    services.addsingleton<imodulecontainer>(this);

    // 添加日志等基础设施组件。
    services.addcoreservices();
    // 添加核心的 abp 服务，主要是模块系统相关组件。
    services.addcoreabpservices(this, options);

    // 加载模块，并按照依赖关系排序，依次执行他们的生命周期方法。
    modules = loadmodules(services, options);
}

提示：

这里的对象访问器其实就是一个占位的类型对象，这样方面后面替换其具体实现。例如在上文当中的 iserviceprovider 通过 objectaccessor<t> 对象包裹起来，其值是 null，但是在后面我们可以根据自己的需要替换其具体的 value 。

2.3 替换 ioc 容器

再回到之前调用 addapplication<t>() 传递的委托方法，在其内部我们调用了 useautofac() 方法。这个方法很简单，内部就只有三行代码。

这三行代码主要是初始化了一个 autofac 的容器构建对象，其次注入 iserviceproviderfactory 和 abp 的默认实现 abpautofacserviceproviderfactory 。

public static void useautofac(this abpapplicationcreationoptions options)
{
    var builder = new containerbuilder();
    options.services.addobjectaccessor(builder);
    // 这里是实例注册。
    options.services.addsingleton((iserviceproviderfactory<containerbuilder>) new abpautofacserviceproviderfactory(builder));
}

这个工厂类的就是在构建 iserviceprovider 的时候使用，即 buildserviceproviderfromfactory() 方法。该方法内部逻辑很简单，就是从已经注册的服务集合(iservicecollection)当中获得之前注册的工厂类，通过调用工厂类的 createserviceprovider() 方法构建 iserviceprovider，并作为返回值替换掉默认的 ioc 容器。

public static iserviceprovider buildserviceproviderfromfactory([notnull] this iservicecollection services)
{
    check.notnull(services, nameof(services));

    // 遍历已经注册的类型，找到之前注入的工厂类。
    foreach (var service in services)
    {
        var factoryinterface = service.implementationinstance?.gettype()
            .gettypeinfo()
            .getinterfaces()
            .firstordefault(i => i.gettypeinfo().isgenerictype &&
                                 i.getgenerictypedefinition() == typeof(iserviceproviderfactory<>));

        if (factoryinterface == null)
        {
            continue;
        }

        // 通过反射调用 iserviceprovider 的构建方法。
        var containerbuildertype = factoryinterface.generictypearguments[0];
        return (iserviceprovider)typeof(servicecollectioncommonextensions)
            .gettypeinfo()
            .getmethods()
            .single(m => m.name == nameof(buildserviceproviderfromfactory) && m.isgenericmethod)
            .makegenericmethod(containerbuildertype)
            .invoke(null, new object[] { services, null });
    }

    return services.buildserviceprovider();
}

// 这里是另外一个重载方法的定义。
public static iserviceprovider buildserviceproviderfromfactory<tcontainerbuilder>([notnull] this iservicecollection services, action<tcontainerbuilder> builderaction = null)
{
    check.notnull(services, nameof(services));

    var serviceproviderfactory = services.getsingletoninstanceornull<iserviceproviderfactory<tcontainerbuilder>>();
    if (serviceproviderfactory == null)
    {
        throw new abpexception($"could not find {typeof(iserviceproviderfactory<tcontainerbuilder>).fullname} in {services}.");
    }

    var builder = serviceproviderfactory.createbuilder(services);
    builderaction?.invoke(builder);
    return serviceproviderfactory.createserviceprovider(builder);
}

2.3 初始化 abp 框架

这里针对 iapplicationbuilder 的扩展是在模块包 volo.abp.aspnetcore 当中的，这里仅讲解 asp.net core mvc 项目是如何处理的。

public static void initializeapplication([notnull] this iapplicationbuilder app)
{
    check.notnull(app, nameof(app));

    // 获取 iapplicationbuilde 的对象访问器，并将其值设置为 app。
    app.applicationservices.getrequiredservice<objectaccessor<iapplicationbuilder>>().value = app;
    
    // 获得之前在 configureservice 注册的 provider 类型，并调用其初始化方法。
    app.applicationservices.getrequiredservice<iabpapplicationwithexternalserviceprovider>().initialize(app.applicationservices);
}

这里可能会疑惑 objectaccessor<iapplicationbuilder> 是在什么时候注入的，其实该类型是在 abpaspnetcoremodule 模块注册的。

public class abpaspnetcoremodule : abpmodule
{
    // ... 其他代码
    public override void configureservices(serviceconfigurationcontext context)
    {
        // ... 其他代码
        context.services.addobjectaccessor<iapplicationbuilder>();
    }
    // ... 其他代码
}

接着看初始化方法内部的操作，初始化方法定义是在基类当中，方法名是 initializemodules() ，在方法内部，通过 imodulemanager 来执行模块的初始化方法。

protected virtual void initializemodules()
{
    using (var scope = serviceprovider.createscope())
    {
        scope.serviceprovider
            .getrequiredservice<imodulemanager>()
            .initializemodules(new applicationinitializationcontext(scope.serviceprovider));
    }
}

除了模块的初始化，模块的销毁动作 abp vnext 好像是没有作处理，你可以挂载 iapplicationlifetime.applicationstopping 事件来手动执行模块的销毁方法。

三、总结

总体来说 abp vnext 的启动流程与之前精简了许多，这是因为在新的框架当中将许多基础组件从核心层移除了，用户可以*选择自己需要加载的组件。ioc 相关的代码则是通过的 microsoft dependency 提供的 iserviceprovider/iservicecollection 进行操作，没有了之前的 iocmanager。