理解ASP.NET MVC系列之二：URL Routing機制:RouteTable

經典的ASP.NET應用程序，當我們請求頁面時，通常每一個頁面請求都會映射到網站中的一個物理頁面。

ASP.NET MVC不是以這種方式工作的。當我們請求一個ASP.NET MVC程序的地址時，網站中不一定存在著對應的頁面。一般來說，對於ASP.NET MVC網站，我們不會再去請求有著.aspx擴展名的地址，而是請求一個有意義的虛擬地址，ASP.NET MVC通過RouteTable，將這個請求轉發到一個叫Controller的類上，Controller負責生成內容並把它發回瀏覽器。

所以，在ASP.NET MVC中，就用RouteTable來定義各種URL到實際處理程序之間的映射。

具體而言，是由Route類來指定ASP.NET 應用程序中針對虛擬路徑請求的處理方法。

你可以為每種URL模式來創建一個Route對象。

而RouteTable的routes屬性是Route對象的集合。

創建RouteTable

這裡有三個問題需要思考：

（1）何時創建？

（2）在哪裡創建？

（3）如何創建？

答案：

（1）何時創建？

在請求處理之前。

（2）在哪裡創建？

在Global.asax.cs文件的Application_Start中（註冊）。

（3）如何創建？

下面是VS2010新建ASP.NET MVC項目時默認的Global.aspx.cs文件的代碼片段：

在此文件中，應用程序默認為路由增加了2個路由對象:

第一個路由是用於忽略特殊請求的路由，這個路由忽略所有擴展名為.axd的請求，這些請求會按照WebForm經典的方式進行處理。

第二個路由由映射任何符合{controller}/{action}/{id}模式是URL到MvcRouteHandler。它還提供了一個默認的參數。

思考：

那麼，ASP.NET MVC又是如何通過RouteTable將請求映射到ASP.NET的處理管道中進行處理的呢？

其實，在ASP.NET MVC中，HttpApplication的處理管道並沒有發生變化，變化的只有處理程序部分。

在經典方式下，我們會通過請求路徑來定位具體的處理程序或者文件，如果找不到則會返回404錯誤。所以，必須要在HttpApplication尋找處理程序之前，必須設置一個肯定可以找到的處理器的請求路徑。

ASP.NET MVC也是如此。

那對於上邊的那個思考問題，答案就是：UrlRoutingModule負責解決這個問題。

UrlRoutingModule事件處理

當我們對ASP.NET MVC應用程序發起請求的時候，請求被送入HttpApplication的處理管道，UrlRoutingModule註冊了HttpApplication的PostResolveRequestCache事件和PostMapRequestHandler事件。

在HttpApplication尋找處理程序之前，設置一個肯定可以找到的處理器的請求路徑。此時，激發了PostResolveRequestCache事件。

當HttpApplication完成處理程序查詢，並成功初始化處理程序之後，在通過RouteTable將處理程序設置到HttpApplication中。此時，激發PostMapRequestHandler事件。

下面說一下這兩個事件的具體處理步驟：

（1）UrlRoutingModule在PostResolveRequestChche事件中做的第一件事就是包裝當前的HttpContext為HttpContextWrapper2。

（2）接著把HttpContextWrapper2傳給RouteTable，RouteTable根據參數返回一個匹配的路由對象：RouteData。

（3）如果UrlRoutingModule成功獲取到RouteData，則會創建HttpContext對象和RouteData的RouteContext路由對象。

（4）然後把RouteContext路由對象傳遞給Handler的構造函數，實例化出一個新的HttpHandler；同時把此路由對象RouteContext通過HttpContext對象的Items集合保存起來，以便在PostMapRequestHandler中使用。

（5）最後通過HttpContext的ReWritePath方法，將當前請求路徑設置為一個肯定存在的路徑。

（6）當PostMapRequestHandler事件觸發時，ASP.NET已完成了經典的獲取處理程序的操作。UrlRoutingModule將檢查通過HttpContext對象的Items保存的路由對象，然後通過路由對象的參數來設置當前的處理程序。