一、簡要說明 本篇文章主要分析 Abp vNext 當中的模塊系統,從類型構造層面上來看,Abp vNext 當中不再只是單純的通過 來管理其他的模塊,它現在則是 和 來協同工作,其他的代碼邏輯並無太大變化。 Abp vNext 規定每個模塊必須繼承自 介面,這樣 vNext 系統在啟動的時候才會掃 ...
一、簡要說明
本篇文章主要分析 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<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()
方法中,基本邏輯如下:
- 掃描當前應用程式的所有模塊類,並構建模塊描述對象。
- 基於模塊描述對象,使用拓撲排序演算法來按照模塊的依賴性進行排序。
- 排序完成之後,遍歷排序完成的模塊描述對象,依次執行它們的三個生命周期方法。
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 抽象出來可能是為了後面方便擴展吧,如果你也有自己的看法不妨在評論區留言。
三、總結
至此,整個模塊系統的解析就結束了,如果看過 Abp 框架源碼解析的朋友就可以很明顯的感覺到,新框架的模塊系統除了生命周期多了幾個以外,其他的變化很少,基本沒太大的變化。
在 Abp vNext 框架裡面,模塊系統是整個框架的基石,瞭解了模塊系統以後,對於剩下的設計就很好理解了。