ASP.NET中路由模型的工作原理是什么

ASP.NET中路由模型的工作原理是什么，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

首先我們先來了解下一個請求的悲歡離合的命運，看看它的一生中所走過的蜿蜒曲折的道路。如下圖所示：

在如上所示的風光旖旎的畫卷中，我們可以看到一個“請求”從客戶端瀏覽器出發，經歷千山萬水到達服務器，服務器的內核模塊的HTTP.SYS熱情款待了它，對它進行簡單的修飾之后，就和它依依惜別了，因為HTTP.SYS知道它是一個有夢想的“請求”，它應該去它該去的地方，于是就把它送到了IIS。

IIS是片神奇的土地，這里有一位偉大的神靈叫做inetinfo.exe，于是它便去神靈的居所W3SVC服務（windows服務）祈禱，希望能給他一些指示，神靈通過查閱天書（IIS的配置文件），知道了它不是一般的靜態文件，不能把它直接送回去，應該讓它去它的族人開辦的加工廠（即對應網站的工作進程中）好好修習一番。

現任加工廠老大叫w3wp.exe，在IIS6以前是aspnet_wp.exe,其因為沒有管理好各個加工廠之間的地盤問題被罷免了（asp.net_wp.exe用一個進程寄宿所有的網站，用應用程序域進行分割的，結果導致網站之間相互影響），現任老大w3wp.exe通過一個網站一個進程的方式把問題解決了，因此順利上位。

初入加工廠的“請求”拜訪了門衛asp.net_isapi.dll,門衛發現它是第一個過來的“請求”，于是為它打開了工廠的生產車間（即第一個請求到達時，啟動了asp.net運行的環境，后來的請求就可以直接進入這個環境里。），并請車間主任ISAPIRuntime來負責它，主任興高采烈的來歡迎它（即ISAPIRuntime調用ProcessRequest（簡稱PR）方法，訪問當前請求所在的ecb句柄），并讓土里土氣的它換上了統一服裝HttpWorkRequest（即把請求進行簡單的封裝），然后叫來班長HttpRuntime,讓班長安排它的工作。

班長說：”車間里面有危險，你先穿上安全制服HttpContext。”（即通過PR方法把HttpWorkRequest封裝成HttpContext），然后去組長宿舍（HttpApplicationFactory）準備叫一個組長（HttpApplication）來帶領它，結果發現還沒有組長，班長只好去招聘一個新組長。

每一個組長都是經過嚴格訓練才能上崗的，先要熟讀入廠準則Global.asax（即先編譯Global.asax文件），再通過準則中Application_Start方法考驗（即調用Application＿Start方法），如此這般方成為一代組長。每位新任組長第一件事就是把所有的車間模塊裝配好，并創建好車間管道（通過讀取配置文件，加載所有的IHttpModule，并調用他們的Init方法，一般init方法都是注冊管道事件，之后通過BuidStepManager方法，根據經典模式或者集成模式生成對應的StepManager）。

新任組長見到“請求”，二話不說直接啟動車間管道，將其丟進去。穿著安全制服HttpContext的“請求”要依次通過管道中所有的關卡（asp.net管道模型），其中在第7個關卡之后，生成了IHttpHandler類型的對象，并在第11個關卡之后執行該對象的ProcessRequest方法處理請求，在這里“請求”得到完美的加工塑造，生成了HttpResponse，再通過剩下的管道，實現了夢想的請求就沿著原路返回了。上圖中第11、12個事件之間描述的是WebForm的Page對象處理請求的流程（即頁面生命周期）。

至此，一個請求的跌宕起伏的人生就說完了，各位觀眾欲知路由模塊具體怎么發揮作用的，還請先捧個人場，右下角點個贊。

action*0x2：路由模型解析

通過上文我們知道組長HttpApplication對象會負責組裝所有的IHttpModule，它是如何加載的呢？我們觀察反編譯的代碼：

private void InitModules()
{
HttpModuleCollection modules = RuntimeConfig.GetAppConfig().HttpModules.CreateModules();
HttpModuleCollection other = this.CreateDynamicModules();
modules.AppendCollection(other);
this._moduleCollection = modules;
this.InitModulesCommon();
}

RuntimeConfig.GetAppConfig().HttpModules.CreateModules();通過這行代碼，我們可以清楚的發現它讀取了運行時的配置文件，那么我們打開運行時的配置文件以觀究竟。

果然在這里add了一個System.WebRouting.UrlRoutingModule類型。接下來我們再用反編譯工具看這個類型的源碼：

如我們所料UrlRoutingModule實現了IHttpModule接口，我們看看它的Init方法干了些什么？

protected virtual void Init(HttpApplication application)
{
if (application.Context.Items[_contextKey] == null)
{
application.Context.Items[_contextKey] = _contextKey;
application.PostResolveRequestCache += new EventHandler(this.OnApplicationPostResolveRequestCache);
}
}

對第7個事件PostResolveRequestCache注冊方法OnApplicationPostResolveRequestCache，那么這個方法又是干啥的呢？

public virtual void PostResolveRequestCache(HttpContextBase context)
{
RouteData routeData = this.RouteCollection.GetRouteData(context);//匹配路由，得到匹配結果RouteData。
if (routeData != null)
{
IRouteHandler routeHandler = routeData.RouteHandler;
if (routeHandler == null)
{
throw new InvalidOperationException(string.Format(CultureInfo.CurrentCulture, SR.GetString("UrlRoutingModule_NoRouteHandler"), new object[0]));
}
if (!(routeHandler is StopRoutingHandler))
{
RequestContext requestContext = new RequestContext(context, routeData);
context.Request.RequestContext = requestContext;
IHttpHandler httpHandler = routeHandler.GetHttpHandler(requestContext);//獲取處理當前請求的IHttpHandler對象。
if (httpHandler == null)
{
object[] args = new object[] { routeHandler.GetType() };
throw new InvalidOperationException(string.Format(CultureInfo.CurrentUICulture, SR.GetString("UrlRoutingModule_NoHttpHandler"), args));
}
if (httpHandler is UrlAuthFailureHandler)
{
if (!FormsAuthenticationModule.FormsAuthRequired)
{
throw new HttpException(0x191, SR.GetString("Assess_Denied_Description3"));
}
UrlAuthorizationModule.ReportUrlAuthorizationFailure(HttpContext.Current, this);
}
else
{
context.RemapHandler(httpHandler);//映射：用當前IHttpHandler對象處理請求。
}
}
}
}

代碼已經加了注釋，3步走：匹配路由→獲取處理當前請求的IHttpHandler對象→映射：用當前IHttpHandler對象處理請求。之后會在第11、12個事件之間調用IHttpHandler對象的PR方法處理當前請求。

我們再整理下思路：ASP.NET先注冊了UrlRoutingModule模塊，他就是一個實現了IHttpModule接口的類，其Init方法就是在第7個事件上注冊一個方法，該方法先匹配路由，如果匹配成功了，則用匹配結果RouteData中的IHttpHandler對象映射到當前上下文中，這樣在之后第11、12個事件之間就會調用這個IHttpHandler對象處理請求。

那么問題來了，Route對象是什么時候注入進去的，IHttpHandler對象又是誰？

還記得路由規則是怎么添加的嗎？如下面代碼所示：

public class Global : System.Web.HttpApplication
{
protected void Application_Start(object sender, EventArgs e)
{
var defaults = new RouteValueDictionary();
defaults.Add("name", "*");
//方式一：
//通過RouteTable的靜態對象Routes新增一個Route類型的對象。
RouteTable.Routes.Add("app", new Route("app/{name}", defaults, new MyRouteHandler()));
//方式二：
//通過RouteTable的靜態對象Routes的擴展方法新增一個路由規則。
RouteTable.Routes.MapPageRoute("default", "app/{name}", "~/WebForm1.aspx", false, defaults);
}
}

這是我們經常用的兩種方式添加路由規則，方式一中有我們自己編寫的MyRouteHandler類型的實例作為參數，其實就是通過IRouteHandler接口返回一個IHttpHandler對象。

/// <summary>
/// 實現了IRouteHandler接口的類型
/// </summary>
internal class MyRouteHandler : IRouteHandler
{
public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
//返回一個Page對象，用于處理請求。
return new WebForm1();
}
}

其實這兩種方式沒有本質上的區別，因為方式二中路由規則參數都會實例化一個Route對象的。

我們分析方式二的源代碼：

public Route MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary defaults, RouteValueDictionary constraints, RouteValueDictionary dataTokens)
{
if (routeUrl == null)
{
throw new ArgumentNullException("routeUrl");
}
Route item = new Route(routeUrl, defaults, constraints, dataTokens, new PageRouteHandler(physicalFile, checkPhysicalUrlAccess));
this.Add(routeName, item);
return item;
}

發現所有的路由規則參數都用來實例化一個Route對象了，其中參數physicalFile和checkPhysicalUrlAccess用來實例化PageRouteHandler對象了，其源碼如下：

public class PageRouteHandler : IRouteHandler
{
}

這是一個實現了IRouteHandler接口的類型，而這個接口只有一個作用就是返回IHttpHandler對象，源碼如下：

[TypeForwardedFrom("System.Web.Routing, Version=3.5.0.0, Culture=Neutral, PublicKeyToken=31bf3856ad364e35")]
public interface IRouteHandler
{
// Methods
IHttpHandler GetHttpHandler(RequestContext requestContext);
}

到這里我們的疑問就解開了，原來我們注冊的路由規則都實例化成了Route對象，Route的GetRouteData方法用來匹配路由，路由規則中的physicalFile和checkPhysicalUrlAccess用來實例化一個IHttpHandler實例，用來處理請求。

總結：ASP.NET的路由模型如下圖所示

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。