天天看點

深入探究ASP.NET Core Startup初始化

前言

    Startup類相信大家都比較熟悉,在我們使用ASP.NET Core開發過程中經常用到的類,我們通常使用它進行IOC服務注冊,配置中間件資訊等。雖然它不是必須的,但是将這些操作統一在Startup中做處理,會在實際開發中帶來許多友善。當我們談起Startup類的時候你有沒有好奇過以下幾點

  • 為何我們自定義的Startup可以正常工作。
  • 我們定義的Startup類中ConfigureServices和Configure隻能叫這個名字才能被調用到嗎?
  • 在使用泛型主機(IHostBuilder)時Startup的構造函數,為何隻支援注入IWebHostEnvironment、IHostEnvironment、IConfiguration。
  • ConfigureServices方法為何隻能傳遞IServiceCollection執行個體。
  • Configure方法的參數為何可以是所有在IServiceCollection注冊服務執行個體。
  • 在ASP.NET Core結合Autofac使用的時候為何我們添加的ConfigureContainer方法會被調用。

    帶着以上幾點疑問,我們将在本篇文章中探索Startup的源碼,來了解Startup初始化過程到底為我們做了些什麼。

Startup的另類指定方式

在日常編碼過程中,我們通常使用UseStartup的方式來引入Startup類。但是這并不是唯一的方式,還有一種方式是在配置節點中指定Startup所在的程式集來自動查找Startup類,這個我們可以在GenericWebHostBuilder的構造函數源碼中的找到相關代碼[點選檢視源碼👈]相信熟悉ASP.Net Core啟動流程的同學對GenericWebHostBuilder這個類都比較了解。ConfigureWebHostDefaults方法中其實調用了ConfigureWebHost方法,ConfigureWebHost方法中執行個體化了GenericWebHostBuilder對象,啟動流程不是咱們的重點,是以這裡隻是簡單描述一下。直接找到我們需要的代碼如下所示

//判斷是否配置了StartupAssembly參數     if (!string.IsNullOrEmpty(webHostOptions.StartupAssembly))     {         try         {             //根據你配置的程式集去查找Startup             var startupType = StartupLoader.FindStartupType(webHostOptions.StartupAssembly, webhostContext.HostingEnvironment.EnvironmentName);             UseStartup(startupType, context, services);         }         catch (Exception ex) when (webHostOptions.CaptureStartupErrors)         {            //此處省略代碼省略         }     }           

這裡我們可以看出來,我們需要配置StartupAssembly對應的程式集,它可以通過StartupLoader的FindStartupType方法加載程式集中對應的類。我們還可以看到它還傳遞了EnvironmentName環境變量,至于它起到了什麼作用,我們繼續往下看。

首先我們需要找到webHostOptions.StartupAssembly是如何被初始化的,在WebHostOptions的構造函數中我們找到了StartupAssembly初始化的地方[點選檢視源碼👈]

StartupAssembly = configuration[WebHostDefaults.StartupAssemblyKey];           

從這裡也可以看出來它的值來于配置,它的key來自WebHostDefaults.StartupAssemblyKey這個常量值,最後我們找到了的值為

public static readonly string StartupAssemblyKey = "startupAssembly";           

也就是說隻要我們給startupAssembly配置Startup所在的程式集名稱,它就可以在程式集中查找Startup類進行初始化,如下所示

public static IHostBuilder CreateHostBuilder(string[] args) =>                 Host.CreateDefaultBuilder(args)                     .ConfigureHostConfiguration(config=> {                         List<KeyValuePair<string, string>> keyValuePairs = new List<KeyValuePair<string, string>>();                         //配置Startup所在的程式集名稱                         keyValuePairs.Add(new KeyValuePair<string, string>("startupAssembly", "Startup所在的程式集名稱"));                         config.AddInMemoryCollection(keyValuePairs);                     })                     .ConfigureWebHostDefaults(webBuilder =>                     {                         //這樣的話這裡就可以省略了                         //webBuilder.UseStartup<Startup>();                     });           

回到上面的思路,我們在StartupLoader類中檢視FindStartupType方法,來看下它是通過什麼規則來查找Startup的[點選檢視源碼👈]精簡之後的代碼大緻如下

public static Type FindStartupType(string startupAssemblyName, string environmentName)     {         var assembly = Assembly.Load(new AssemblyName(startupAssemblyName));         //名稱Startup+環境變量的類比如(StartupDevelopment)         var startupNameWithEnv = "Startup" + environmentName;         //名稱為Startup的類         var startupNameWithoutEnv = "Startup";         // 先查找包含名稱Startup+環境變量的相關類,如果找不到則查找名稱為Startup的類         var type =             assembly.GetType(startupNameWithEnv) ??             assembly.GetType(startupAssemblyName + "." + startupNameWithEnv) ??             assembly.GetType(startupNameWithoutEnv) ??             assembly.GetType(startupAssemblyName + "." + startupNameWithoutEnv);         if (type == null)         {             // 如果上述規則找不到,則在程式集定義的所有類中繼續查找             var definedTypes = assembly.DefinedTypes.ToList();             var startupType1 = definedTypes.Where(info => info.Name.Equals(startupNameWithEnv, StringComparison.OrdinalIgnoreCase));             var startupType2 = definedTypes.Where(info => info.Name.Equals(startupNameWithoutEnv, StringComparison.OrdinalIgnoreCase));             var typeInfo = startupType1.Concat(startupType2).FirstOrDefault();             if (typeInfo != null)             {                 type = typeInfo.AsType();             }         }         //最終傳回Startup類型         return type;     }           

通過上述代碼我們可以看到在通過配置指定程式集時是如何查找指定規則的Startup類的,基本上可以了解為先去查找名稱為Startup+環境變量的類,如果找不到則繼續查找名稱為Startup的類,最終會傳回Startup的類型傳遞給UseStartup方法。其實我們最常使用的UseStartup()方法最終也是轉換成UseStartup(typeof(T))的方式,是以最終這兩種方式走到了相同的地方,接下來我們步入正題,來一起探究一下Starup究竟是如何被初始化的。

Startup的構造函數

相信對Startup有所了解的同學們都比較清楚,在使用泛型主機(IHostBuilder)時Startup的構造函數隻支援注入IWebHostEnvironment、IHostEnvironment、IConfiguration,這個在微軟官方文檔中https://docs.microsoft.com/en-us/aspnet/core/fundamentals/startup?view=aspnetcore-3.1#the-startup-class也有介紹,如果還有不熟悉這個操作的請先反思一下自己,然後在查閱微軟官方文檔。接下來我們就從源碼着手,來探究一下它到底是如何做到的。沿着上述的操作,繼續檢視UseStartup裡的代碼找到了如下的實作[點選檢視源碼👈]

//建立Startup執行個體     object instance = ActivatorUtilities.CreateInstance(new HostServiceProvider(webHostBuilderContext), startupType);           

這裡的startupType就是我們傳遞的Startup類型,關于ActivatorUtilities這個類還是比較實用的,它為我們提供了許多幫助我們執行個體化對象的方法,在日常程式設計中如果有需要可以使用這個類。上面的ActivatorUtilities的CreateInstance方法的功能就是根據傳遞IServiceProvider類型的對象去執行個體化指定的類型對象,我們這裡的類型就是startupType。它的使用場景就是,如果某個類型需要用過有參構造函數去執行個體化,而構造函數的參數可以來自于IServiceProvider的執行個體,那麼使用這個方法就在合适不過了。上面的代碼傳遞的IServiceProvider的執行個體是HostServiceProvider對象,接下來我們找到它的實作源碼[點選檢視源碼👈]代碼并不多我們就全部粘貼出來

private class HostServiceProvider : IServiceProvider     {         private readonly WebHostBuilderContext _context;         public HostServiceProvider(WebHostBuilderContext context)         {             _context = context;         }         public object GetService(Type serviceType)         {             // 通過這裡我們就比較清晰的看出,隻有滿足這幾種情況下才能傳回具體的執行個體,其他的都會傳回null             #pragma warning disable CS0618 // Type or member is obsolete             if (serviceType == typeof(Microsoft.Extensions.Hosting.IHostingEnvironment)                 || serviceType == typeof(Microsoft.AspNetCore.Hosting.IHostingEnvironment)             #pragma warning restore CS0618 // Type or member is obsolete                 || serviceType == typeof(IWebHostEnvironment)                 || serviceType == typeof(IHostEnvironment)                 )             {                 return _context.HostingEnvironment;             }             if (serviceType == typeof(IConfiguration))             {                 return _context.Configuration;             }             //不滿足這幾種情況的類型都傳回null             return null;         }     }           

通過這個内部私有類我們就能清晰的看到為何Starup的構造函數隻能注入IWebHostEnvironment、IHostEnvironment、IConfiguration相關執行個體了,HostServiceProvider類實作了IServiceProvider的GetService方法并做了判斷,隻有滿足這幾種類型才能傳回具體的執行個體注入,其它不滿足條件的類型都會傳回null。是以在初始化Starup執行個體的時候,通過構造函數注入的類型也就隻能是這幾種了。最終通過這個構造函數初始化了Startup類的執行個體。

ConfigureServices的裝載

接下來我們就來在UseStartup方法裡繼續檢視是如何查找并執行ConfigureServices方法的,繼續檢視找到如下實作[點選檢視源碼👈]

//傳遞startupType和環境變量參數查找傳回ConfigureServicesBuilder     var configureServicesBuilder = StartupLoader.FindConfigureServicesDelegate(startupType, context.HostingEnvironment.EnvironmentName);     //調用Build方法傳回ConfigureServices委托     var configureServices = configureServicesBuilder.Build(instance);     //傳遞services對象即IServiceCollection對象調用ConfigureServices方法     configureServices(services);           

從上述代碼中我們可以了解到查找并執行ConfigureServices方法的具體步驟可分為三步,首先在startupType類型中根據環境變量名稱查找具體方法傳回ConfigureServicesBuilder執行個體,然後建構ConfigureServicesBuilder執行個體傳回ConfigureServices方法的委托,最後傳遞IServiceCollection對象執行委托方法。接下來我們就來檢視具體實作源碼。

我們在StartupLoader類中找到了FindConfigureServicesDelegate方法的相關實作[點選檢視源碼👈]

internal static ConfigureServicesBuilder FindConfigureServicesDelegate(Type startupType, string environmentName)     {         //根據startupType和根據environmentName建構的Configure{0}Services字元串先去查找傳回類型為IServiceProvider的方法         //找不到在查找傳回值為void類型的方法         var servicesMethod = FindMethod(startupType, "Configure{0}Services", environmentName, typeof(IServiceProvider), required: false)             ?? FindMethod(startupType, "Configure{0}Services", environmentName, typeof(void), required: false);         //根據查找的到的MethodInfo去建構ConfigureServicesBuilder執行個體         return new ConfigureServicesBuilder(servicesMethod);     }           

通過這裡的源碼我們可以看到在startupType類型裡去查找名字為environmentName建構的Configure{0}Services的方法資訊,然後根據查找的方法資訊即MethodInfo對象去建構ConfigureServicesBuilder執行個體。接下裡我們就來查詢FindMethod方法的實作

private static MethodInfo FindMethod(Type startupType, string methodName, string environmentName, Type returnType = null, bool required = true)     {         //包含環境變量的ConfigureServices方法名稱比如(ConfigureDevelopmentServices)         var methodNameWithEnv = string.Format(CultureInfo.InvariantCulture, methodName, environmentName);         //名為ConfigureServices的方法         var methodNameWithNoEnv = string.Format(CultureInfo.InvariantCulture, methodName, "");         //方法是共有的靜态的或非靜态的方法         var methods = startupType.GetMethods(BindingFlags.Public | BindingFlags.Instance | BindingFlags.Static);         //查找包含環境變量的ConfigureServices方法名稱         var selectedMethods = methods.Where(method => method.Name.Equals(methodNameWithEnv, StringComparison.OrdinalIgnoreCase)).ToList();         if (selectedMethods.Count > 1)         {             //找打多個滿足規則的方法直接抛出異常             throw new InvalidOperationException(string.Format("Having multiple overloads of method '{0}' is not supported.", methodNameWithEnv));         }         //如果不存在包含環境變量的ConfigureServices的方法比如(ConfigureDevelopmentServices),則直接查找方法名為ConfigureServices的方法         if (selectedMethods.Count == 0)         {             selectedMethods = methods.Where(method => method.Name.Equals(methodNameWithNoEnv, StringComparison.OrdinalIgnoreCase)).ToList();             //如果存在多個則同樣抛出異常             if (selectedMethods.Count > 1)             {                 throw new InvalidOperationException(string.Format("Having multiple overloads of method '{0}' is not supported.", methodNameWithNoEnv));             }         }         var methodInfo = selectedMethods.FirstOrDefault();         //如果沒找到滿足規則的方法,并且滿足required參數,則抛出未找到方法的異常         if (methodInfo == null)         {             if (required)             {                 throw new InvalidOperationException(string.Format("A public method named '{0}' or '{1}' could not be found in the '{2}' type.",                     methodNameWithEnv,                     methodNameWithNoEnv,                     startupType.FullName));             }             return null;         }         //如果找到了名稱一緻的方法,但是傳回類型和預期的不一緻,也抛出異常         if (returnType != null && methodInfo.ReturnType != returnType)         {             if (required)             {                 throw new InvalidOperationException(string.Format("The '{0}' method in the type '{1}' must have a return type of '{2}'.",                     methodInfo.Name,                     startupType.FullName,                     returnType.Name));             }             return null;         }         return methodInfo;     }           

通過FindMethod方法我們可以得到幾個結論,首先ConfigureServices方法的名稱可以是包含環境變量的名稱比如(ConfigureDevelopmentServices),其次方法可以為共有的靜态或非靜态方法。FindMethod方法是真正執行查找的邏輯所在,如果找到相關方法則傳回MethodInfo。FindMethod查找的方法名稱是通過methodName參數傳遞進來的,我們标注的注釋代碼都是直接寫死了ConfigureServices方法,隻是為了便于說明了解,但其實FindMethod是通用方法,接下來我們要講解的内容還會涉及到這個方法,到時候關于這個代碼的邏輯我們就不會在進行說明了,因為是同一個方法,希望大家能注意到這一點。

通過上面的相關方法,我們了解到了是通過什麼樣的規則去查找到ConfigureServices的方法資訊的,我們也看到了ConfigureServicesBuilder正是通過查找到的MethodInfo去構造執行個體的,接下來我們就來檢視下ConfigureServicesBuilder的實作源碼[點選檢視源碼👈]

internal class ConfigureServicesBuilder     {         //構造函數傳遞的configureServices的MethodInfo         public ConfigureServicesBuilder(MethodInfo configureServices)         {             MethodInfo = configureServices;         }         public MethodInfo MethodInfo { get; }         public Func<Func<IServiceCollection, IServiceProvider>, Func<IServiceCollection, IServiceProvider>> StartupServiceFilters { get; set; } = f => f;         //Build委托         public Func<IServiceCollection, IServiceProvider> Build(object instance) => services => Invoke(instance, services);         private IServiceProvider Invoke(object instance, IServiceCollection services)         {             //執行StartupServiceFilters委托參數為Func<IServiceCollection, IServiceProvider>類型的委托方法即Startup             //傳回了Func<IServiceCollection, IServiceProvider>委托,執行這個委托需傳遞services即IServiceCollections執行個體傳回IServiceProvider類型             return StartupServiceFilters(Startup)(services);             IServiceProvider Startup(IServiceCollection serviceCollection) => InvokeCore(instance, serviceCollection);         }         private IServiceProvider InvokeCore(object instance, IServiceCollection services)         {             if (MethodInfo == null)             {                 return null;             }             // 如果ConfigureServices方法包含多個參數或方法參數類型不是IServiceCollection類型則直接抛出異常             // 也就是說ConfigureServices隻能包含一個參數且類型為IServiceCollection             var parameters = MethodInfo.GetParameters();             if (parameters.Length > 1 ||                 parameters.Any(p => p.ParameterType != typeof(IServiceCollection)))             {                 throw new InvalidOperationException("The ConfigureServices method must either be parameterless or take only one parameter of type IServiceCollection.");             }             //找到ConfigureServices方法的參數,并将services即IServiceCollection的執行個體傳遞給這個參數             var arguments = new object[MethodInfo.GetParameters().Length];             if (parameters.Length > 0)             {                 arguments[0] = services;             }             // 執行傳回IServiceProvider執行個體             return MethodInfo.InvokeWithoutWrappingExceptions(instance, arguments) as IServiceProvider;         }     }           

看完ConfigureServicesBuilder類的實作邏輯,關于通過什麼樣的邏輯查找并執行ConfigureServices方法的邏輯就非常清晰了。首先是查找ConfigureServices方法,即包含環境變量的ConfigureServices方法名稱比如(ConfigureDevelopmentServices)或名為ConfigureServices的方法,傳回的是ConfigureServicesBuilder對象。然後執行ConfigureServicesBuilder的Build方法,這個方法裡包含了執行ConfigureServices的規則,即ConfigureServices隻能包含一個參數且類型為IServiceCollection,然後将目前程式中存在的IServiceCollection執行個體傳遞給它。

Configure的裝載

我們常使用Startup的Configure方法去配置中間件,預設生成的Configure方法為我們添加了IApplicationBuilder和IWebHostEnvironment執行個體,但是其實Configure方法不僅僅可以傳遞這兩個參數,它可以通過參數注入在IServiceCollection中注冊的所有服務,究竟是如何實作的呢,接下來我們繼續探究UseStartup方法查找源碼檢視想實作

[點選檢視源碼👈],我們抽離出來核心實作如下

//和ConfigureServices查找方式類似傳遞Startup執行個體和環境變量     ConfigureBuilder configureBuilder = StartupLoader.FindConfigureDelegate(startupType, context.HostingEnvironment.EnvironmentName);     services.Configure<GenericWebHostServiceOptions>(options =>     {         //通過檢視GenericWebHostServiceOptions的源碼可知app其實就是IApplicationBuilder執行個體         options.ConfigureApplication = app =>         {             startupError?.Throw();             //執行Startup.Configure,instance為Startup執行個體             if (instance != null && configureBuilder != null)             {                   //執行Configure方法傳遞Startup執行個體和IApplicationBuilder執行個體                 configureBuilder.Build(instance)(app);             }         };     });           

我們通過檢視GenericWebHostServiceOptions的源碼可知ConfigureApplication屬性的類型為Action也就是說app參數其實就是IApplicationBuilder接口的執行個體。通過上面這段代碼可以看出,主要邏輯就是調用StartupLoader的FindConfigureDelegate方法,然後傳回ConfigureBuilder建造類,然後建構出Configure方法并執行。首先我們來檢視FindConfigureDelegate的邏輯實作

[點選檢視源碼👈]

internal static ConfigureBuilder FindConfigureDelegate(Type startupType, string environmentName)     {         //通過startup類型和方法名為Configure或Configure+環境變量名稱的方法         var configureMethod = FindMethod(startupType, "Configure{0}", environmentName, typeof(void), required: true);         //用查找到的方法去初始化ConfigureBuilder         return new ConfigureBuilder(configureMethod);     }           

從這裡我們可以看到FindConfigureDelegate方法也是調用的FindMethod方法,隻是傳遞的方法名字元串為Configure或Configure+環境變量,關于FindMethod的方法實作我們在上面講解ConfigureServices方法的時候已經非常詳細的說過了,這裡就不過多的講解了。總之是通過FindMethod去查找名為Configure的方法或名為Configure+環境變量的方法比如ConfigureDevelopment查找規則和ConfigureServices是完全一緻的。但是Configure方法卻可以通過參數注入注冊到IServiceCollection中的服務,答案我們同樣要在ConfigureBuilder類中去探尋

internal class ConfigureBuilder     {         //構造函數傳遞Configure的MethodInfo         public ConfigureBuilder(MethodInfo configure)         {             MethodInfo = configure;         }         public MethodInfo MethodInfo { get; }         //Build方法傳回Action<IApplicationBuilder>委托         public Action<IApplicationBuilder> Build(object instance) => builder => Invoke(instance, builder);         //執行邏輯         private void Invoke(object instance, IApplicationBuilder builder)         {             //通過IApplicationBuilder的ApplicationServices擷取IServiceProvider執行個體建立一個作用域             using (var scope = builder.ApplicationServices.CreateScope())             {                 //擷取IServiceProvider執行個體                 var serviceProvider = scope.ServiceProvider;                 //擷取Configure的所有參數                 var parameterInfos = MethodInfo.GetParameters();                 var parameters = new object[parameterInfos.Length];                 for (var index = 0; index < parameterInfos.Length; index++)                 {                     var parameterInfo = parameterInfos[index];                     //如果方法參數為IApplicationBuilder類型則直接将傳遞過來的IApplicationBuilder指派給它                     if (parameterInfo.ParameterType == typeof(IApplicationBuilder))                     {                         parameters[index] = builder;                     }                     else                     {                         try                         {                             //根據方法的參數類型在serviceProvider中擷取具體執行個體指派給對應參數                             parameters[index] = serviceProvider.GetRequiredService(parameterInfo.ParameterType);                         }                         catch (Exception ex)                         {                             //如果對應的方法參數名稱,沒在serviceProvider中擷取到則直接抛出異常                             //變相的說明了Configure方法的參數必須是注冊在IServiceCollection中的                         }                     }                 }                 MethodInfo.InvokeWithoutWrappingExceptions(instance, parameters);             }         }     }           

通過ConfigureBuilder類的實作邏輯,可以清晰的看到為何Configure方法參數可以注入任何在IServiceCollection中注冊的服務了。接下來我們總結一下Configure方法的初始化邏輯,首先在Startup中查找方法名為Configure或Configure+環境變量名稱(比如ConfigureDevelopment)的方法,然後查找IApplicationBuilder類型的參數,如果找到則将程式中的IApplicationBuilder執行個體傳遞給它。至于為何Configure方法能夠通過參數注入任何在IServiceCollection中注冊的服務,則是因為循環Configure中的所有參數然後在IOC容器中擷取對應執行個體指派過來,Configure方法的參數一定得是在IServiceCollection注冊過的類型,否則會抛出異常。

ConfigureContainer為何會被調用

如果你在ASP.NET Core 3.1中使用過Autofac那麼你對ConfigureContainer方法一定不陌生,它和ConfigureServices、Configure方法一樣的神奇,在幾乎沒有任何限制的情況下我們隻需要定義ConfigureContainer方法并為方法傳遞一個ContainerBuilder參數,那麼這個方法就能順利的被調用了。這一切究竟是如何實作的呢,接下來我們繼續探究源碼,找到了如下的邏輯

//根據規則查找最終傳回ConfigureContainerBuilder執行個體     var configureContainerBuilder = StartupLoader.FindConfigureContainerDelegate(startupType, context.HostingEnvironment.EnvironmentName);     if (configureContainerBuilder.MethodInfo != null)     {         //擷取容器類型比如如果是autofac則類型為ContainerBuilder         var containerType = configureContainerBuilder.GetContainerType();         // 存儲configureContainerBuilder執行個體         _builder.Properties[typeof(ConfigureContainerBuilder)] = configureContainerBuilder;         //建構一個Action<HostBuilderContext,containerType>類型的委托         var actionType = typeof(Action<,>).MakeGenericType(typeof(HostBuilderContext), containerType);         // 擷取此類型的私有ConfigureContainer方法,然後聲明該方法的泛型為容器類型,然後建立這個方法的委托         var configureCallback = GetType().GetMethod(nameof(ConfigureContainer), BindingFlags.NonPublic | BindingFlags.Instance)                                          .MakeGenericMethod(containerType)                                          .CreateDelegate(actionType, this);         // 等同于執行_builder.ConfigureContainer<T>(ConfigureContainer),其中T為容器類型。         //C onfigureContainer表示一個委托,即我們在Startup中定義的ConfigureContainer委托         typeof(IHostBuilder).GetMethods().First(m => m.Name == nameof(IHostBuilder.ConfigureContainer))             .MakeGenericMethod(containerType)             .InvokeWithoutWrappingExceptions(_builder, new object[] { configureCallback });     }           

繼續使用老配方,我們檢視StartupLoader的FindConfigureContainerDelegate方法實作

internal static ConfigureContainerBuilder FindConfigureContainerDelegate(Type startupType, string environmentName)     {         //根據startupType和根據environmentName建構的Configure{0}Services字元串先去查找傳回類型為IServiceProvider的方法         var configureMethod = FindMethod(startupType, "Configure{0}Container", environmentName, typeof(void), required: false);         //用查找到的方法去初始化ConfigureContainerBuilder         return new ConfigureContainerBuilder(configureMethod);     }           

果然還是這個配方這個味道,廢話不多說直接檢視ConfigureContainerBuilder源碼

internal class ConfigureContainerBuilder     {         public ConfigureContainerBuilder(MethodInfo configureContainerMethod)         {             MethodInfo = configureContainerMethod;         }         public MethodInfo MethodInfo { get; }         public Func<Action<object>, Action<object>> ConfigureContainerFilters { get; set; } = f => f;         public Action<object> Build(object instance) => container => Invoke(instance, container);         //查找容器類型,其實就是ConfigureContainer方法的的唯一參數         public Type GetContainerType()         {             var parameters = MethodInfo.GetParameters();             //ConfigureContainer方法隻能包含一個參數             if (parameters.Length != 1)             {                 throw new InvalidOperationException($"The {MethodInfo.Name} method must take only one parameter.");             }             return parameters[0].ParameterType;         }         private void Invoke(object instance, object container)         {             ConfigureContainerFilters(StartupConfigureContainer)(container);             void StartupConfigureContainer(object containerBuilder) => InvokeCore(instance, containerBuilder);         }         //根據傳遞的container對象執行ConfigureContainer方法邏輯比如使用autofac時ConfigureContainer(ContainerBuilder)         private void InvokeCore(object instance, object container)         {             if (MethodInfo == null)             {                 return;             }             var arguments = new object[1] { container };             MethodInfo.InvokeWithoutWrappingExceptions(instance, arguments);         }     }           

果不其然千年老方下來還是那個味道,和ConfigureServices、Configure方法思路幾乎一緻。這裡需要注意的是GetContainerType擷取的容器類型是ConfigureContainer方法的唯一參數即容器類型,如果傳遞多個參數則直接抛出異常。其實Startup的ConfigureContainer方法經過花裡胡哨的一番操作之後,最終還是轉換成了雷士如下的操作方式,這個我們在上面代碼中建構actionType的時候就可以看出,最終通過查找到的容器類型去完成注冊等相關操作,這裡就不過多的講解了

Host.CreateDefaultBuilder(args)             .ConfigureContainer<ContainerBuilder>((context,container)=> {                 container.RegisterType<PersonService>().As<IPersonService>().InstancePerLifetimeScope();             });           

總結

    本篇文章我們主要是圍繞着Startup是如何被初始化進行講解的,分别講解了Startup是如何被執行個體化的,為何Startup的構造函數隻能傳遞IWebHostEnvironment、IHostEnvironment、IConfiguration類型的參數,以及ConfigureServices、Configure、ConfigureContainer方法是如何查找到并被初始化調用的。其中雖然涉及到的代碼比較多,但是整體思路在閱讀源碼後還是比較清晰的。由于筆者文筆有限,可能許多地方描述的不夠清晰,亦或是本人能力有限了解的不夠透徹,不過本人在文章中都标記了源碼所在位置的連結,如果有感興趣的同學可以自行點選連接配接檢視源碼。Startup類比較常用,如果能夠更深層次的了解其原理,對我們實際程式設計過程中會有很大的幫助,同時呼籲更多的小夥伴們深入閱讀了解.NET Core的源碼并分享出來。如有各位有疑問或者有了解的更透徹的,歡迎評論區提問或批評指導。

👇歡迎掃碼關注我的公衆号👇

深入探究ASP.NET Core Startup初始化