您好,登錄后才能下訂單哦!
IApplicationBuilder 是應用大家最熟悉它的地方應該就是位于 Startup.cs 文件中的 Configure 方法了吧
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory){ app.UseDeveloperExceptionPage(); app.UseStaticFiles(); app.UseMvc(); }
IApplicationBuilder 就像其名字一樣,其實很簡單,就是對內做了一個接口封裝,對外提供了一個擴展,具體來說就是
對內封裝了
IServiceProvider ApplicationServices { get; set; }:應用程序使用的服務,就是ConfigureServices注入的那些。
IFeatureCollection ServerFeatures { get; }: 工具箱對象,下面會提到的。
IDictionary<string, object> Properties { get; } :橫跨各個中間件,在他們之間共享數據。
對外擴展了
IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware):注冊中間件
還有一個 Build 用來返回管道最終的 HttpContext 狀態
RequestDelegate Build(); : 最終的 RequestDelegate 形態
沒什么復雜的東西,就這幾個東西需要了解,下面是一個 IApplicationBuilder 的貼圖,看起來應該會更直觀。
那 RequestDelegate 又是什么東西呢?
RequestDelegate
RequestDelegate 是一個委托,是以委托形式對 HttpContext 的封裝,在 ASP.NET Core 中也是非常重要的一個對象,先看一下定義吧。
namespace Microsoft.AspNetCore.Http{ public delegate Task RequestDelegate(HttpContext context); }
為什么說這個對象很重要呢,因為在管道中所有的中間件都是直接或者間接的使用到它來做一些功能,因為它包裝這 HttpContext 的嘛,而在Web開發中 HttpContext 的地位又是如此的高,接下來就說說 HttpContext。
HttpContext 應該是做Web開發最熟悉的一個對象了,在這個對象中,封裝著Http整個管道中的關鍵對象信息,這個對象同時伴隨著整個管道中傳輸,也就是會經歷整個請求的生命周期,所以這個對象非常重要,也是學習Web開發的一個基礎知識。
與傳統 .NET Framework 中的 System.Web.HttpContext 不同的是,在 ASP.NET Core 中 HttpContext 是一個抽象類,位于 Microsoft.AspNetCore.Http 命名空間下。它有一個默認的實現叫 DefaultHttpContext位于 Microsoft.AspNetCore.Http 程序集。
我們知道以前的 System.Web.HttpContext 是怎么創建的吧?
在傳統ASP.NET程序中,IIS接收到請求之后,會交給 aspnet_isapi.dll 這個程序集,程序集啟動 ASP.NET 運行環境,然后調用 ISAPIRuntime 進行封裝,封裝之后就是一個 HttpWorkRequest 對象了,然后由 HttpRuntime將其轉化為一個HttpContext。
所以在System.Web.HttpContext中,其構造函數為 HttpWorkerRequest
namespace System.Web { public sealed class HttpContext : IServiceProvider, IPrincipalContainer { public HttpContext(HttpWorkerRequest wr); } }
也就是說其實構建HttpContext所有的信息都是來自于 IIS 傳遞下來的 HttpWorkerRequest。
現在,忘了它吧,是的全部忘掉,這個時候你又要罵微軟了,尼瑪當年為了面試這個東西不知道背了多少遍。 =_=
沒辦法,時代要發展要進步,我們也需要不斷的學習,那在 ASP.NET Core 中,沒有了 IIS ,它的 HttpContext 又是如何生成的呢? 構建 HttpContext 所需的信息又怎么來的呢? 客官不要著急,聽我慢慢分解
IFeatureCollection
這里就需要先說一下另外一個比較重要接口了,它就是 IFeatureCollection 接口,這個接口是干嘛的呢? 我們先看一下它的定義:
public interface IFeatureCollection : IEnumerable<KeyValuePair<Type, object>> { bool IsReadOnly { get; } int Revision { get; } object this[Type key] { get; set; } TFeature Get<TFeature>(); void Set<TFeature>(TFeature instance); }
看到這個接口的定義應該能夠明白其功能了,接口繼承于IEnumerable<KeyValuePair<Type, object>> 說明接口是一個鍵值對的集合,我們給接口取個名字吧,叫“工具箱”。
有些同學應該猜出來了,是的,ASP.NET Core中構建 HttpContext 就是所有需要的組件都是來自于 工具箱,那么 工具箱 里面都有什么呢?可以看到工具箱里面有 IHttpRequestFeature, IHttpResponseFeature, ISessionFeature 等等還有很多就不一一列舉了,正是由于這一個一個的工具箱里面的工具,最終構建成為了整個 HttpContext 對象。我們來看一下 HttpContext 對象的構造函數:
namespace Microsoft.AspNetCore.Http{ public class DefaultHttpContext : HttpContext { public DefaultHttpContext(IFeatureCollection features) { Initialize(features); } } }
沒錯吧,有同學可能要問了,工具箱里面的這些工具什么時候初始化的呢? 先別急,我們先看看我們熟悉的 Request 和 Response。
HttpRequest
同樣在 ASP.NET Core ,HttpRequest 也成為了一個抽象類,它的默認實現叫 DefaultHttpRequest,主要是封裝瀏覽器對服務器的請求的各種數據,包括瀏覽器請求的網址,查詢字符串數據或表單數據等等...
不一一詳細介紹了,都是很簡單的內容。
HttpResponse
HttpResponse 也成為了一個抽象類,它的默認實現叫 DefaultHttpResponse,主要是是服務器接收到瀏覽器的請求后,處理返回結果常用的一個對象。
是時候該解釋一下上面的 工具箱 初始化的問題了,我想我用一個圖來直接說明管道中的請求再合適不過了,下面就是一個 ASP.NET Core 整個服務端構建管道一個流程圖:
從圖中可以看到,RequestDelegate 攜帶著 HttpContext 一路經過各種 Server、Hosting 等,最終到達了由 IApplicationBuilder 構建出來的 Application pipeline 這一管道區域,然后再經過各種中間件處理,最終構建出來了我們的 Response,而我們的工具箱 也正是在這個過程中變得 “ 飽滿 ” 起來。
有一個需要知道的知識點就是,中間件是怎么樣添加或者叫注冊到管道中的呢? 又是如何被應用起來的呢?
上面的圖可以看到,橙色區域的 Application pipeline 是由 IApplicationBuilder 構建起來的。也就是說我們可以在 IApplicationBuilder 做點什么東西來添加我們的中間件。 是的 IApplicationBuilder 暴露出來了一個 IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware); 方法來讓我們注冊中間件,也就是說位于 Startup.cs 文件中的 Configure 方法。
那么又是怎么樣應用起來的呢? IApplicationBuilder 在 Hosting 中有一個 IApplicationBuilderFactory 的對象,Hosting 通過這個Factory 創建之后就會傳遞到了 HostingApplication 對象中,最后由 IWebHost 對象調用 IServer 對象的Start 同時把 HostingApplication傳遞進去來最終啟動服務端。可以對照上面的圖理解一下。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。