新版本URL-rewrite module for IIS 7.0的發(fā)布了，ASP.NET Routing組件隨著.NET Framework 3.5 SP1的發(fā)布，并在.NET Framework 4.0 Beta中進(jìn)一步成熟。作為ASP.NET 開發(fā)人員，我們不免會(huì)對(duì)這兩個(gè)功能相近的組件抱有許多疑問，諸如“它們有什么異同？”“分別適用于什么環(huán)境？”等等。本文旨在描述這兩者之間的異同，并為開發(fā)人員提供什么時(shí)候使用哪一種解決方案的建議。

　　從表面上看來，這兩種技術(shù)似乎提供了非常相似的功能：為網(wǎng)站提供用戶友好的、搜索引擎友好的Url。然而，在這兩種技術(shù)在原理上卻有著本質(zhì)的區(qū)別，需要深入理解才能在選擇應(yīng)用時(shí)做出正確的決策。為了幫助大家理解這兩種技術(shù)，我們首先從他們的運(yùn)作原理開始講起。

　　本文翻譯自IIS官方網(wǎng)站，針對(duì)國(guó)內(nèi)慣用的術(shù)語(yǔ)進(jìn)行了部分調(diào)整。

　　URL重寫(URL Rewriting)

　　URL Rewriting已經(jīng)不是什么新技術(shù)了，大約在10年前就已經(jīng)在Apache服務(wù)器上廣泛應(yīng)用。由于它被公認(rèn)為是web管理員和開發(fā)人員的法寶，許多流行的基于Apache的網(wǎng)站都依賴于Url重寫來提供“優(yōu)雅”的Url。

　　簡(jiǎn)單的說，URL重寫的理念非常簡(jiǎn)單：當(dāng)一個(gè)客戶端向服務(wù)端請(qǐng)求一個(gè)特定的URL時(shí)，URL重寫模塊會(huì)分析所請(qǐng)求的URL并把請(qǐng)求更改，指向同一Web服務(wù)器上的另一個(gè)URL。在web請(qǐng)求周期中插入U(xiǎn)RL重寫模塊（如通過HttpModule）非常簡(jiǎn)單，所以，它能夠在服務(wù)器處理請(qǐng)求之前來修改所請(qǐng)求的URL。而服務(wù)端的處理程序會(huì)根據(jù)重寫后的URL來生成一個(gè)Response到客戶端瀏覽器。由于重寫過程發(fā)生在服務(wù)端，所以客戶端瀏覽器根本看不到重寫后的URL，在客戶端看來，他所收到的Response來自原來所請(qǐng)求的URL。

　　在IIS 7.0的架構(gòu)中，這個(gè)過程可以由下圖來展示：

　　微軟所提供的URL重寫模塊(URL-rewrite module)是一個(gè)native-code的模塊，插入web請(qǐng)求處理過程的Pre-begin Request 或 Begin Request 階段，然后通過所配置的一系列重寫規(guī)則來進(jìn)行URL重寫。每一個(gè)重寫規(guī)則對(duì)URL進(jìn)行正則分析，判斷是否當(dāng)前所請(qǐng)求的URL滿足重寫規(guī)則所定義的條件，如果滿足，就根據(jù)規(guī)則將原來的URL重寫成一個(gè)新的URL。當(dāng)所有的重寫規(guī)則都過了一遍之后，URL重寫模塊會(huì)生成一個(gè)最終的URL路徑，傳遞給剩余的請(qǐng)求處理過程。也就是說IIS管道中的請(qǐng)求處理程序所處理的是在URL重寫模塊所寫后的URL。

　　ASP.NET路由(ASP.NET Routing)

　　從本質(zhì)上來說，ASP.NET路由是一種請(qǐng)求調(diào)度機(jī)制，它允許開發(fā)者將符合指定規(guī)則的URL關(guān)聯(lián)給一個(gè)能夠處理這個(gè)請(qǐng)求的Handler來進(jìn)行處理。這種關(guān)聯(lián)通過注冊(cè)定義了URL映射關(guān)系的“Routes”來完成。當(dāng)一個(gè)請(qǐng)求到達(dá)服務(wù)端時(shí)，ASP.NET路由模塊會(huì)查找已經(jīng)注冊(cè)的Routes表，如果匹配到了某個(gè)Route，那么Route相應(yīng)的Handler就會(huì)被調(diào)用來處理這個(gè)請(qǐng)求。

　　在IIS 7.0的架構(gòu)中，這個(gè)過程可以由下圖來展示：

　　ASP.NET路由是由托管代碼來實(shí)現(xiàn)的，作為插件嵌入到IIS請(qǐng)求處理管道的Resolve Cache步驟(PostResolveRequestCache 事件)和Map Handler 步驟(PostMapRequestHandler)中。ASP.NET路由會(huì)被配置為對(duì)Web Application全局的請(qǐng)求都生效。

　　在PostResolveRequestCache事件過程中，路由模塊會(huì)查找一個(gè)路由表（一個(gè)route對(duì)象的集合），來查找匹配所請(qǐng)求URL的Route。如果找到了匹配的Route，ASP.NET路由模塊會(huì)獲取一個(gè)處理這個(gè)Route的handler，并把這個(gè)handler的引用保存到當(dāng)前的HttpContext中去。當(dāng)然，這個(gè)handler可以是實(shí)現(xiàn)了System.Web.IHttpHandler接口的任何類（比如Page類）。如果沒能夠找到匹配的Route，那么ASP.NET路由模塊就什么也不做，任由這個(gè)請(qǐng)求走完剩下的處理過程（通常會(huì)映射到一個(gè)硬盤文件如XX.ASPx）。

　　在PostMapRequestHandler事件過程中，路由模塊會(huì)檢查當(dāng)前的HttpContext是否包含一個(gè)handler的信息，如果有的話，ASP.NET路由模塊就會(huì)把當(dāng)前HttpContext的Handler屬性設(shè)置成所找到的handler。這樣就讓IIS在Execute Handler步驟中執(zhí)行路由模塊所選中的handler。如果沒有的話，ASP.NET路由模塊就什么也不做，讓IIS來選擇一個(gè)handler處理這個(gè)URL請(qǐng)求。

　　URL 重寫和ASP.NET 路由的區(qū)別

　　基于上面的說明，我們可以看出，URL重寫和ASP.NET路由在概念上的差別有如下幾點(diǎn)：

1. URL重寫用來在Web服務(wù)器處理請(qǐng)求之前處理URL。URL重寫模塊不知道究竟什么handler會(huì)被用來處理重寫后的URL，相同，這個(gè)最終的handler也不知道這個(gè)URL是否被重寫過了。
2. ASP.NET路由用來根據(jù)URL來為一個(gè)請(qǐng)求指派相應(yīng)的處理程序（handler），與URL重寫相反，路由組件知道相關(guān)的handler，并且親自選擇handler來處理所請(qǐng)求的URL。鑒于此點(diǎn)，我們也可以把ASP.NET路由想作是一個(gè)高級(jí)的處理映射(handler-mapping)機(jī)制。

　　除了概念上的差別，URL重寫和ASP.NET路由在功能上也有如下幾點(diǎn)差別：

1. IIS URL重寫模塊可以用于任何類型的web應(yīng)用程序，包括ASP.NET, php, ASP甚至靜態(tài)文件。而ASP.NET路由則只能處理基于.NET Framework的web應(yīng)用程序。
2. IIS URL重寫模塊在集成（integrated）和經(jīng)典（classic） IIS管道模式的應(yīng)用程序池中的運(yùn)行是一樣的。而ASP.NET路由則偏向于應(yīng)用集成（integrated）管道模式。ASP.NET路由也可以在經(jīng)典（classic） 模式下運(yùn)行，但這時(shí)程序中的URL必須包含文件擴(kuò)展名，或者程序在IIS中必須配置一個(gè)”*”的handler映射。
3. URL重寫模塊可以通過域名、Http頭信息、服務(wù)器變量來決定是否進(jìn)行重寫。而默認(rèn)的情況下，ASP.NET路由只能通過URL路徑和Http頭信息中的HTTP-Method信息來決定是否進(jìn)行路由。
4. 除了URL重寫，IIS URL重寫模塊還可以來做HTTP跳轉(zhuǎn)、設(shè)置自定義的IIS狀態(tài)代碼，甚至終止請(qǐng)求。而ASP.NET路由不能做這些。
5. IIS URL重寫模塊在目前的版本中是不能擴(kuò)展的，而ASP.NET路由則是完全可擴(kuò)展、可定制的。

　　我們?cè)撊绾芜x擇?

　　知道了這些異同，我們應(yīng)該怎樣在應(yīng)用中挑選合適的URL優(yōu)化方案呢？我們將在下節(jié)中來探討。

NET技術(shù)：IIS URL Rewriting 和 ASP.NET routing（上），轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。