前言
前面有2篇文章提到了關於URL Routing的特性,但是發現有很多人誤會URL Routing就是URl Rewriting,其實2個雖然都提供相似的功能(提高友好的URL方便搜尋引起收錄),但是2者的原理和運行周期是完全不一樣的,本篇文章我們就來分析一下具體有什麼不同。
例子
在分析原理之前,我們先來做一個例子測試一下(IIS URL Rewrite模組需要IIS7的支援)。
1.為Customer/1的URL建立對應的MVC程式
首先建立一個普通的MVC3程式,建立一個簡單的CustomerController以及一個簡單的Detail action,代碼如下:
public class CustomerController : Controller{ public ActionResult Detail(string id) { ViewBag.CustomerID = id; return View(); }}
我們只是簡單的接受一個ID,然後放到ViewBag裡以便在view裡顯示,view的代碼如下:
@{ Layout = null;}<!DOCTYPE html><html><head> <title>Detail</title></head><body> <div> MVC下運行結果:@ViewBag.CustomerID </div></body></html>
2.為Customer/1的URL建立對應的web form程式
在同一個解決方案的根目錄下,建立一個Customer.aspx檔案,檔案代碼主要是接受一個ID參數然後顯示在頁面上,代碼:
public partial class Customer : System.Web.UI.Page{ protected void Page_Load(object sender, EventArgs e) { this.lblId.InnerText = Request.QueryString["id"]; }}
html:
<form id="form1" runat="server"> <div> asp.net web form下是:<label runat="server" id="lblId"></label> </div></form>
OK,我們先在Global.asax.cs裡配置Customre/1的route,代碼如下:
routes.MapRoute( "CustomerDetail", // Route name "Customer/{id}", // URL with parameters new { controller = "Customer", action = "Detail", id = UrlParameter.Optional });
編譯訪問,運行http://localhost/customer/123,頁面顯示結果是:
MVC下運行結果:123。
3.安裝IIS URL Rewrite
到如下地址下載並安裝IIS URL Rewrite,http://www.iis.net/download/URLRewrite 成功安裝以後,在MVC項目的web.config裡配置一條URL重寫規則,代碼如下(注意是system.webServer節點哦):
<system.webServer> <validation validateIntegratedModeConfiguration="false"/> <modules runAllManagedModulesForAllRequests="true"/> <directoryBrowse enabled="true" /> <rewrite> <rules> <rule name="rewrite customer"> <match url="^customer/([0-9]+)" /> <action type="Rewrite" url="customer.aspx?id={R:1}" /> </rule> </rules> </rewrite></system.webServer>
該規則的意思是,將customer/1類似的請求重寫到customer.aspx?id=1上,我們編譯器再來訪問以下http://localhost/customer/123,頁面顯示結果如下:
asp.net web form下是:123
也就是說Routing在這個時候沒起作用,因為URL Rewrite是在Routing之前將Customer/123這個地址轉寄到了Customer.aspx?id=123,由aspx檔案接收請求了。我們來看看2者之間到底都是在什麼周期處理的。
原理周期
1. URL Rewrite
關於URL Rewrite最早見於apache web server,當時風靡一時的url重寫讓一大批使用php的人欣喜若狂啊,可惜之前由於asp.net下的實現方式特別複雜,所以很多站的基本上都沒怎麼用,自從IIS.net推出正式的IIS URL Rewrite模組以來,徹底解決了這一問題。
URL Rewrite是在request-processing pipeline的早期階段執行的,一般一個地址進來以後,該模組會根據規則來映射到同一伺服器上的另外一條新的地址,新地址在處理的時候所接受的參數和資料都是一句新地址的參數來判斷的,就比如customer.aspx?id=123,而 request裡的url也是新的地址,而不是重寫之前的地址,不過使用者本身感覺不到變化,因為瀏覽器上顯示的一直是舊URL,我們來看一下他的循環圖表。
URL Rewrite module是一個native的模組,從圖可以看到他的運行周期是在Pre-begin Rquest和Begin Request之間,該模組在根據請求的URL進行規則匹配之後,最終處理新的URL以便進入IIS pipeline的剩餘周期裡進行處理,就是說處理請求的HttpHandler是根據重寫以後的新URL來決定的。
2. URL Routing
URL Routing的原理是根據現有的URL來定義規則,定義每個規則所對應的HttpHandler,其本質和URL是否友好沒有關係,只是按照統一的規則去調用相對應的HttpHandler而已,找到對應的HttpHandler,處理完以後就返回結果,找不到就暴資源錯誤。
Routing是Managed 程式碼模組,是在Resolve Cache周期( PostResolveRequestCache事件)裡註冊,然後在MapHandler周期內處理的。在PostResolveRequestCache事件裡,該模組查詢靜態集合routing表裡的所有記錄裡聲明的URL匹配規則,如果當前URL對應到了一個匹配的Handler,然後就使用該Handler處理結果並輸出。
兩者之間的不同
URL Rewrite是在request處理之前修改相應的URL,URL Rewrite模組本身不知道哪個HttpHandler處理這個請求,並且處理請求的HttpHandler也不知道自己處理的URL是原來的URL還是被重寫過的地址。
和URL Rewrite正好相反,URL Routing是根據規則為URL來指定HttpHandler的,可以看做Routing是handler的進階映射。
IIS URL Rewrite可以用於任何web程式的映射處理,包括但不限於asp.net,php,asp和靜態檔案等,但Routing只能處理基於.net的web程式。
IIS URL Rewrite在IIS整合模式和傳統模式都可以用,但預設情況下Routing只能用在整合模式下,傳統模式的話需要使用副檔名或者萬用字元將程式映射到IIS上(其實.net有另外一個組件aspnetfilter已經幫我們做好了)。
IIS URL Rewrite可以根據網域名稱,路徑,Http Header,server變數等處理重寫規則,但Routing只能按照請求的URL路徑和HTTP-Method header來處理。
IIS URL Rewrite可以執行處理HTTP跳轉,處理自訂的Status Code以及Abort請求,但Routing做不到這些。
IIS URL Rewrite的擴充只能擴充自己的Provider來自訂規則的儲存,但Routing的擴充相對來說就非常強大了,MVC就是其中一種。
總結
兩者之間有這麼多不同,那我們到底該用哪一個呢?
如果你的程式是用asp.net之外的平台構建的,那你只能使用IIS URL Rewrite了,否則,我們建議的規則是:
如果你在用asp.net構建新的asp.net web程式,那就使用Routing,因為現在Routing不僅支援MVC了,也支援web form了。
如果你的asp.net web form程式已經是現成的了,並且不想修改了,那就使用URL Rewrite,它可以幫你改善搜尋引擎最佳化。
當然,你也可以兩者結合起來一起用,但是用之前一定要記得上面的圖裡所說明的內容:他們的執行循環不一樣。
參考地址:http://learn.iis.net/page.aspx/496/iis-url-rewriting-and-aspnet-routing/
以上這篇ASP.NET中URL Routing和IIS上URL Rewriting的區別就是小編分享給大家的全部內容了,希望能給大家一個參考,也希望大家多多支援雲棲社區。