[Abp vNext 原始碼分析] – 2. 模組系統的變化

一、簡要說明

本篇文章主要分析 Abp vNext 當中的模組系統，從型別構造層面上來看，Abp vNext 當中不再只是單純的透過 AbpModuleManager 來管理其他的模組，它現在則是 IModuleManager 和 IModuleLoader 來協同工作，其他的程式碼邏輯並無太大變化。

Abp vNext 規定每個模組必須繼承自 IAbpModule 介面，這樣 vNext 系統在啟動的時候才會掃描到相應的模組。與原來 Abp 框架一樣，每個模組可以透過 DependsOnAttribute 特性來確定依賴關係，演演算法還是使用拓撲排序演演算法，來根據依賴性確定模組的載入順序。(從最頂層的模組，依次載入，直到啟動模組。)

以我們的 Demo 專案為例，這裡透過拓撲排序之後的依賴關係如上圖，這樣最開始執行的即 AbpDataModule 模組，然後再是 AbpAuditingModule 以此類推，直到我們的啟動模組 DemoAppModule。

在 Abp vNext 當中，所有的元件庫/第三方庫都是以模組的形式呈現的，模組負責管理整個庫的生命週期，包括註冊元件，配置元件，銷毀元件等。

在最開始的 Abp 框架當中，一個模組有 4 個生命週期，它們都是在抽象基類 AbpModule 當中定義的，分別是 預載入、初始化、初始化完成、銷毀。前三個生命週期是依次執行的 預載入->初始化->初始化完成，而最後一個銷毀動作則是在程式終止的時候，透過 AbpModuleManager 遍歷模組，呼叫其 ShutDown() 方法進行銷毀動作。

新的 Abp vNext 框架除了原有的四個生命週期以外，還抽象出了 IOnPreApplicationInitialization、IOnApplicationInitialization、IOnPostApplicationInitialization、IOnApplicationShutdown。從名字就可以看出來，新的四個生命週期是基於應用程式級別的，而不是模組級別。

這是什麼意思呢？在 Abp vNext 框架當中，模組按照功能用途劃分為兩種型別的模組。第一種是 框架模組，它是框架的核心模組，比如快取、EF Core 等基礎設施就屬於框架模組，其模組的邏輯與處理基本都在傳統的三個生命週期進行處理。

在我們的 services.AddApplication（） 階段就已經完成所有初始化，可以給 應用程式模組 提供服務。

第二種則是 應用程式模組，這種模組則是實現了特定的業務/功能，例如身份管理、租戶管理等，而新增加的四個生命週期基本是為這種型別的模組服務的。

在程式碼和結構上來說，兩者並沒有區別，在這裡僅僅是按用途進行了一次分類。單就模組系統來說，其基本的作用就類似於一個配置類，配置某種元件的各種引數和一些預設邏輯。

二、原始碼分析

2.1 模組系統的基礎設施

模組的初始化動作是在 AbpApplicationBase 基類開始的，在該基類當中除了註入模組相關的基礎設施以外。還定義了模組的初始化方法，即 LoadModules() 方法，在該方法內部是呼叫的 IModuleLoader 去執行具體的載入操作。

internal AbpApplicationBase(
    [NotNull] Type startupModuleType,
    [NotNull] IServiceCollection services,
    [CanBeNull] Action optionsAction)
{
    Check.NotNull(startupModuleType, nameof(startupModuleType));
    Check.NotNull(services, nameof(services));

    
    StartupModuleType = startupModuleType;
    Services = services;

    services.TryAddObjectAccessor();

    var options = new AbpApplicationCreationOptions(services);
    optionsAction?.Invoke(options);

    
    services.AddSingleton(this);
    services.AddSingleton(this);

    services.AddCoreServices();
    
    services.AddCoreAbpServices(this, options);

    
    Modules = LoadModules(services, options);
}

private IReadOnlyList LoadModules(IServiceCollection services, AbpApplicationCreationOptions options)
{
    
    return services
        .GetSingletonInstance()
        .LoadModules(
            services,
            StartupModuleType,
            options.PlugInSources
        );
}

2.2 模組的初始化

進入 IModuleLoader 的預設實現 ModuleLoader，在它的 LoadModules() 方法中，基本邏輯如下：

1. 掃描當前應用程式的所有模組類，並構建模組描述物件。
2. 基於模組描述物件，使用拓撲排序演演算法來按照模組的依賴性進行排序。
3. 排序完成之後，遍歷排序完成的模組描述物件，依次執行它們的三個生命週期方法。

public IAbpModuleDescriptor[] LoadModules(
    IServiceCollection services,
    Type startupModuleType,
    PlugInSourceList plugInSources)
{
    
    Check.NotNull(services, nameof(services));
    Check.NotNull(startupModuleType, nameof(startupModuleType));
    Check.NotNull(plugInSources, nameof(plugInSources));

    
    var modules = GetDescriptors(services, startupModuleType, plugInSources);

    
    modules = SortByDependency(modules, startupModuleType);
    
    
    ConfigureServices(modules, services);

    return modules.ToArray();
}

在搜尋模組型別的時候，是使用的 AbpModuleHelper 工具類提供的 .FindAllModuleTypes() 方法。該方法會將我們的啟動模組傳入，根據模組上面的 DependsOn() 標簽遞迴構建 模組描述物件 的集合。

private List GetDescriptors(
    IServiceCollection services,
    Type startupModuleType,
    PlugInSourceList plugInSources)
{
    
    var modules = new List();

    
    FillModules(modules, services, startupModuleType, plugInSources);
    
    SetDependencies(modules);

    
    return modules.Cast().ToList();
}

protected virtual void FillModules(
    List modules,
    IServiceCollection services,
    Type startupModuleType,
    PlugInSourceList plugInSources)
{
    
    foreach (var moduleType in AbpModuleHelper.FindAllModuleTypes(startupModuleType))
    {
        modules.Add(CreateModuleDescriptor(services, moduleType));
    }
    
    
}

走進 AbpModuleHelper 靜態類，其程式碼與結構與原有的 Abp 框架類似，首先看下它的 FindAllModuleTypes() 方法，根據啟動模組的型別遞迴查詢所有的模組型別，並新增到一個集合當中。

public static List FindAllModuleTypes(Type startupModuleType)
{
    var moduleTypes = new List();
    
    AddModuleAndDependenciesResursively(moduleTypes, startupModuleType);
    return moduleTypes;
}

private static void AddModuleAndDependenciesResursively(List moduleTypes, Type moduleType)
{
    
    AbpModule.CheckAbpModuleType(moduleType);

    
    if (moduleTypes.Contains(moduleType))
    {
        return;
    }

    moduleTypes.Add(moduleType);

    
    foreach (var dependedModuleType in FindDependedModuleTypes(moduleType))
    {
        AddModuleAndDependenciesResursively(moduleTypes, dependedModuleType);
    }
}

public static List FindDependedModuleTypes(Type moduleType)
{
    AbpModule.CheckAbpModuleType(moduleType);

    var dependencies = new List();

    
    var dependencyDescriptors = moduleType
        .GetCustomAttributes()
        .OfType();

    
    foreach (var descriptor in dependencyDescriptors)
    {
        
        foreach (var dependedModuleType in descriptor.GetDependedTypes())
        {
            dependencies.AddIfNotContains(dependedModuleType);
        }
    }

    return dependencies;
}

以上操作完成之後，我們就能獲得一個平級的模組描述物件集合，我們如果要使用拓撲排序來重新針對這個集合進行排序，就需要知道每個模組的依賴項，根據 IAbpModuleDescriptor 的定義，我們可以看到它有一個 Dependencies 集合來儲存它的依賴項。

public interface IAbpModuleDescriptor
{
    
    Type Type { get; }

    
    Assembly Assembly { get; }

    
    IAbpModule Instance { get; }

    
    bool IsLoadedAsPlugIn { get; }

    
    IReadOnlyList Dependencies { get; }
}

而 SetDependencies(List modules) 方法就是來設定每個模組的依賴項的，程式碼邏輯很簡單。遍歷之前的平級模組描述物件集合，根據當前模組的型別定義，找到其依賴項的型別定義。根據這個型別定義去平級的模組描述物件集合搜尋，將搜尋到的結果儲存到當前的模組描述物件中的 Dependencies 屬性當中。

protected virtual void SetDependencies(List modules)
{
    
    foreach (var module in modules)
    {
        SetDependencies(modules, module);
    }
}

protected virtual void SetDependencies(List modules, AbpModuleDescriptor module)
{
    
    foreach (var dependedModuleType in AbpModuleHelper.FindDependedModuleTypes(module.Type))
    {
        
        var dependedModule = modules.FirstOrDefault(m => m.Type == dependedModuleType);
        if (dependedModule == null)
        {
            throw new AbpException("Could not find a depended module " + dependedModuleType.AssemblyQualifiedName + " for " + module.Type.AssemblyQualifiedName);
        }

        
        module.AddDependency(dependedModule);
    }
}

最後的拓撲排序就不在贅述，關於拓撲排序的演演算法，可以在我的 這篇 博文當中找到。

關於模組的最後操作，就是執行模組的三個生命週期方法了，這塊程式碼在 ConfigureServices() 方法當中，沒什麼特別的的處理，遍歷整個模組描述物件集合，依次執行幾個方法就完了。

只是在這裡的生命週期方法與之前的不一樣了，這裡會為每個方法傳入一個服務背景關係物件，主要是可以透過 IServiceCollection 來配置各個模組的引數，而不是原來的 Configuration 屬性。

protected virtual void ConfigureServices(List modules, IServiceCollection services)
{
    
    var context = new ServiceConfigurationContext(services);
    services.AddSingleton(context);

    foreach (var module in modules)
    {
        if (module.Instance is AbpModule abpModule)
        {
            abpModule.ServiceConfigurationContext = context;
        }
    }

    
    foreach (var module in modules.Where(m => m.Instance is IPreConfigureServices))
    {
        ((IPreConfigureServices)module.Instance).PreConfigureServices(context);
    }

    
    foreach (var module in modules)
    {
        if (module.Instance is AbpModule abpModule)
        {
            if (!abpModule.SkipAutoServiceRegistration)
            {
                services.AddAssembly(module.Type.Assembly);
            }
        }

        module.Instance.ConfigureServices(context);
    }

    
    foreach (var module in modules.Where(m => m.Instance is IPostConfigureServices))
    {
        ((IPostConfigureServices)module.Instance).PostConfigureServices(context);
    }

    
    foreach (var module in modules)
    {
        if (module.Instance is AbpModule abpModule)
        {
            abpModule.ServiceConfigurationContext = null;
        }
    }
}

以上動作都是在 Startup 類當中的 ConfigureService() 方法中執行，你可能會奇怪，剩下的四個應用程式生命週期的方法在哪兒執行的呢？

這幾個方法是被抽象成了 IModuleLifecycleContributor 型別，在前面的 AddCoreAbpService()方法的內部就被新增到了配置項裡面。

internal static void AddCoreAbpServices(this IServiceCollection services,
    IAbpApplication abpApplication,
    AbpApplicationCreationOptions applicationCreationOptions)
{
    
    
    services.Configure(options =>
    {
        options.Contributors.Add();
        options.Contributors.Add();
        options.Contributors.Add();
        options.Contributors.Add();
    });
}

執行的話，則是在 Startup 類的 Configure() 方法當中，它會呼叫 AbpApplicationBase 基類的 InitializeModules() 方法，在該方法內部也是遍歷所有的 Contributor (生命週期)，再將所有的模組對應的方法呼叫一次而已。

public void InitializeModules(ApplicationInitializationContext context)
{
    LogListOfModules();

    
    foreach (var Contributor in _lifecycleContributors)
    {
        
        foreach (var module in _moduleContainer.Modules)
        {
            Contributor.Initialize(context, module.Instance);
        }
    }

    _logger.LogInformation("Initialized all modules.");
}

這裡操作可能有點看不懂，不是說呼叫模組的生命週期方法麼，為啥還將實體傳遞給 Contributor 呢？我們找到一個 Contributor 的定義就知道了。

public class OnApplicationInitializationModuleLifecycleContributor : ModuleLifecycleContributorBase
{
    public override void Initialize(ApplicationInitializationContext context, IAbpModule module)
    {
        
        (module as IOnApplicationInitialization)?.OnApplicationInitialization(context);
    }
}

這裡我認為 Abp vNext 把 Contributor 抽象出來可能是為了後面方便擴充套件吧，如果你也有自己的看法不妨在評論區留言。

三、總結

至此，整個模組系統的解析就結束了，如果看過 Abp 框架原始碼解析的朋友就可以很明顯的感覺到，新框架的模組系統除了生命週期多了幾個以外，其他的變化很少，基本沒太大的變化。

在 Abp vNext 框架裡面，模組系統是整個框架的基石，瞭解了模組系統以後，對於剩下的設計就很好理解了。