[Abp vNext 源碼分析] - 2. 模塊系統的變化

時間  2019-11-07
標籤 abp vnext 源碼 分析 模塊 系統 變化 简体版
原文   原文鏈接

1、簡要說明

本篇文章主要分析 Abp vNext 當中的模塊系統，從類型構造層面上來看，Abp vNext 當中再也不只是單純的經過 AbpModuleManager 來管理其餘的模塊，它如今則是 IModuleManager 和 IModuleLoader 來協同工做，其餘的代碼邏輯並沒有太大變化。html

Abp vNext 規定每一個模塊必須繼承自 IAbpModule 接口，這樣 vNext 系統在啓動的時候纔會掃描到相應的模塊。與原來 Abp 框架同樣，每一個模塊能夠經過 DependsOnAttribute 特性來肯定依賴關係，算法仍是使用拓撲排序算法，來根據依賴性肯定模塊的加載順序。(從最頂層的模塊，依次加載，直到啓動模塊。)算法

以咱們的 Demo 項目爲例，這裏經過拓撲排序以後的依賴關係如上圖，這樣最開始執行的即 AbpDataModule 模塊，而後再是 AbpAuditingModule 以此類推，直到咱們的啓動模塊 DemoAppModule。緩存

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

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

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

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

在咱們的 services.AddApplication（） 階段就已經完成全部初始化，能夠給 應用程序模塊 提供服務。源碼分析

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

在代碼和結構上來講，二者並無區別，在這裏僅僅是按用途進行了一次分類。單就模塊系統來講，其基本的做用就相似於一個配置類，配置某種組件的各類參數和一些默認邏輯。插件

2、源碼分析

2.1 模塊系統的基礎設施

模塊的初始化動做是在 AbpApplicationBase 基類開始的，在該基類當中除了注入模塊相關的基礎設施之外。還定義了模塊的初始化方法，即 LoadModules() 方法，在該方法內部是調用的 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);

    // 當前的 Application 就是一個模塊容器。
    services.AddSingleton<IAbpApplication>(this);
    services.AddSingleton<IModuleContainer>(this);

    services.AddCoreServices();
    // 注入模塊加載類，以及模塊的四個應用程序生命週期。
    services.AddCoreAbpServices(this, options);

    // 遍歷全部模塊，並按照預加載、初始化、初始化完成的順序執行其生命週期方法。
    Modules = LoadModules(services, options);
}

private IReadOnlyList<IAbpModuleDescriptor> LoadModules(IServiceCollection services, AbpApplicationCreationOptions options)
{
    // 從 IoC 容器當中獲得模塊加載器。
    return services
        .GetSingletonInstance<IModuleLoader>()
        .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<IAbpModuleDescriptor> GetDescriptors(
    IServiceCollection services, 
    Type startupModuleType,
    PlugInSourceList plugInSources)
{
    // 建立一個空的模塊描述對象集合。
    var modules = new List<AbpModuleDescriptor>();

    // 按照啓動模塊，遞歸構建模塊描述對象集合。
    FillModules(modules, services, startupModuleType, plugInSources);
    // 設置每一個模塊的依賴項。
    SetDependencies(modules);

    // 返回結果。
    return modules.Cast<IAbpModuleDescriptor>().ToList();
}

protected virtual void FillModules(
    List<AbpModuleDescriptor> modules,
    IServiceCollection services,
    Type startupModuleType,
    PlugInSourceList plugInSources)
{
    // 調用 AbpModuleHelper 提供的搜索方法。
    foreach (var moduleType in AbpModuleHelper.FindAllModuleTypes(startupModuleType))
    {
        modules.Add(CreateModuleDescriptor(services, moduleType));
    }
    
    // ... 其餘代碼。
}

走進 AbpModuleHelper 靜態類，其代碼與結構與原有的 Abp 框架相似，首先看下它的 FindAllModuleTypes() 方法，根據啓動模塊的類型遞歸查找全部的模塊類型，並添加到一個集合當中。

public static List<Type> FindAllModuleTypes(Type startupModuleType)
{
    var moduleTypes = new List<Type>();
    // 遞歸構建模塊類型集合。
    AddModuleAndDependenciesResursively(moduleTypes, startupModuleType);
    return moduleTypes;
}

private static void AddModuleAndDependenciesResursively(List<Type> moduleTypes, Type moduleType)
{
    // 檢測傳入的類型是不是模塊類。
    AbpModule.CheckAbpModuleType(moduleType);

    // 集合已經包含了類型定義，則返回。
    if (moduleTypes.Contains(moduleType))
    {
        return;
    }

    moduleTypes.Add(moduleType);

    // 遍歷其 DependsOn 特性定義的類型，遞歸將其類型添加到集合當中。
    foreach (var dependedModuleType in FindDependedModuleTypes(moduleType))
    {
        AddModuleAndDependenciesResursively(moduleTypes, dependedModuleType);
    }
}

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

    var dependencies = new List<Type>();

    // 從傳入的類型當中，得到 DependsOn 特性。
    var dependencyDescriptors = moduleType
        .GetCustomAttributes()
        .OfType<IDependedTypesProvider>();

    // 可能有多個特性標籤，遍歷。
    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<IAbpModuleDescriptor> Dependencies { get; }
}

而 SetDependencies(List<AbpModuleDescriptor> modules) 方法就是來設置每一個模塊的依賴項的，代碼邏輯很簡單。遍歷以前的平級模塊描述對象集合，根據當前模塊的類型定義，找到其依賴項的類型定義。根據這個類型定義去平級的模塊描述對象集合搜索，將搜索到的結果存儲到當前的模塊描述對象中的 Dependencies 屬性當中。

protected virtual void SetDependencies(List<AbpModuleDescriptor> modules)
{
    // 遍歷整個模塊描述對象集合。
    foreach (var module in modules)
    {
        SetDependencies(modules, module);
    }
}

protected virtual void SetDependencies(List<AbpModuleDescriptor> modules, AbpModuleDescriptor module)
{
    // 根據當前模塊描述對象存儲的 Type 類型，得到 DependsOn 標籤依賴的類型。
    foreach (var dependedModuleType in AbpModuleHelper.FindDependedModuleTypes(module.Type))
    {
        // 在模塊描述對象中，按照 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);
        }

        // 搜索到結果，則添加到當前模塊描述對象的 Dependencies 屬性。
        module.AddDependency(dependedModule);
    }
}

最後的拓撲排序就不在贅述，關於拓撲排序的算法，能夠在個人 這篇 博文當中找到。

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

只是在這裏的生命週期方法與以前的不同了，這裏會爲每一個方法傳入一個服務上下文對象，主要是能夠經過 IServiceCollection 來配置各個模塊的參數，而不是原來的 Configuration 屬性。

protected virtual void ConfigureServices(List<IAbpModuleDescriptor> modules, IServiceCollection services)
{
    // 構造一個服務上下文，並將其添加到 IoC 容器當中。
    var context = new ServiceConfigurationContext(services);
    services.AddSingleton(context);

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

    // 執行預加載方法 PreConfigureServices。
    foreach (var module in modules.Where(m => m.Instance is IPreConfigureServices))
    {
        ((IPreConfigureServices)module.Instance).PreConfigureServices(context);
    }

    // 執行初始化方法 ConfigureServices。
    foreach (var module in modules)
    {
        if (module.Instance is AbpModule abpModule)
        {
            if (!abpModule.SkipAutoServiceRegistration)
            {
                services.AddAssembly(module.Type.Assembly);
            }
        }

        module.Instance.ConfigureServices(context);
    }

    // 執行初始化完成方法 PostConfigureServices。
    foreach (var module in modules.Where(m => m.Instance is IPostConfigureServices))
    {
        ((IPostConfigureServices)module.Instance).PostConfigureServices(context);
    }

    // 將服務上下文置爲 NULL。
    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<ModuleLifecycleOptions>(options =>
    {
        options.Contributors.Add<OnPreApplicationInitializationModuleLifecycleContributor>();
        options.Contributors.Add<OnApplicationInitializationModuleLifecycleContributor>();
        options.Contributors.Add<OnPostApplicationInitializationModuleLifecycleContributor>();
        options.Contributors.Add<OnApplicationShutdownModuleLifecycleContributor>();
    });
}

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

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

    // 遍歷應用程序的幾個生命週期。
    foreach (var Contributor in _lifecycleContributors)
    {
        // 遍歷全部的模塊，將模塊實例傳入具體的 Contributor，方便在其內部調用具體的生命週期方法。
        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)
    {
        // 使用模塊實例轉換爲 IOnApplicationInitialization 對象，調用其生命週期方法。
        (module as IOnApplicationInitialization)?.OnApplicationInitialization(context);
    }
}

這裏我認爲 Abp vNext 把 Contributor 抽象出來多是爲了後面方便擴展吧，若是你也有本身的見解不妨在評論區留言。

3、總結

至此，整個模塊系統的解析就結束了，若是看過 Abp 框架源碼解析的朋友就能夠很明顯的感受到，新框架的模塊系統除了生命週期多了幾個之外，其餘的變化不多，基本沒太大的變化。

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

4、點擊我跳轉到文章目錄

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程