快捷導(dǎo)航

ASP.NET中URL Rewrite的具體實(shí)現(xiàn)方法

更新時(shí)間：2013年11月07日 16:29:49 作者：

這篇文章介紹了ASP.NET中URL Rewrite的具體實(shí)現(xiàn)方法，有需要的朋友可以參考一下

之前覺(jué)得這個(gè)話題已經(jīng)被談濫了。URL Rewrite早已經(jīng)被廣大開(kāi)發(fā)人員所接受，網(wǎng)上關(guān)于URL Rewrite的組件和文章也層出不窮，但是總是讓我感覺(jué)意猶未盡，于是最終還是忍不住提筆寫(xiě)了這系列文章。這些文章不會(huì)談?wù)揢RL Rewrite的價(jià)值與意義，而只會(huì)談?wù)摷兗夹g(shù)的內(nèi)容。文章中也不會(huì)有詳盡地實(shí)現(xiàn)分析，而是結(jié)合了我的經(jīng)驗(yàn)，從應(yīng)用角度來(lái)講解這個(gè)話題。您已經(jīng)知道的，您還不知道的，別處已經(jīng)講過(guò)的，或者還沒(méi)有講過(guò)的，希望這系列文章的“舊事重提”不會(huì)讓您覺(jué)得沉悶，并且能讓您了解ASP.NET中URL Rewrite的方方面面。如果您以后再遇到URL Rewrite方面的問(wèn)題是能夠想到這幾篇文章，估計(jì)我做夢(mèng)也會(huì)笑出聲來(lái)。

　　要充分理解文章后面談到的話題，我們必須簡(jiǎn)單的了解一下IIS與ASP.NET的通信過(guò)程。我在這里講解的是IIS 6服務(wù)器。至于IIS 5和IIS 7，前者可以說(shuō)已經(jīng)被淘汰了，而后者的“經(jīng)典模式”與IIS 6可謂如出一轍，而新的“管道模式”其實(shí)是講ASP.NET中的某些概念與IIS進(jìn)行了深度集成。我相信，如果您了解了IIS 6和ASP.NET，在IIS 7的集成模式下也不會(huì)有任何問(wèn)題。

　　首先我們來(lái)看一幅簡(jiǎn)單的示意圖，展示了IIS從收到Request開(kāi)始，到返回Response整個(gè)過(guò)程中的幾個(gè)主要步驟：

IIS收到請(qǐng)求。
選擇器根據(jù)URL的特點(diǎn)與IIS中的配置，選擇一個(gè)ISAPI用于處理該請(qǐng)求——現(xiàn)在自然會(huì)選擇ASP.NET ISAPI。
ASP.NET執(zhí)行引擎接收到請(qǐng)求，于是初始化數(shù)據(jù)（例如構(gòu)建各種對(duì)象）。
開(kāi)始觸發(fā)各種Pipeline事件，自然先從BeginRequest開(kāi)始。
經(jīng)過(guò)了多個(gè)Pipeline事件，ASP.NET根據(jù)配置為當(dāng)前請(qǐng)求選擇一個(gè)合適的Handler或HandlerFactory進(jìn)行處理（當(dāng)然特殊情況例外，例如已經(jīng)在之前的事件中直接輸出結(jié)果并結(jié)束請(qǐng)求了）。
經(jīng)過(guò)了Handler處理之后又經(jīng)過(guò)幾個(gè)Pipeline事件，以EndRequest結(jié)束。
輸出Response。
　　在一個(gè)ASP.NET應(yīng)用中如果要進(jìn)行URL Rewrite，那么一般就是在BeginRequest事件中調(diào)用HttpContext的RewritePath方法，將該請(qǐng)求重新“定位”至一個(gè)目標(biāo)URL。例如我們就可以在Global.asax中重寫(xiě)Application_BeginRequest方法來(lái)實(shí)現(xiàn)這一點(diǎn)：

　　之所以在BeginRequest中進(jìn)行Rewrite，是因?yàn)檫@個(gè)事件是在所有Pipeline事件中最早被觸發(fā)的。在這時(shí)進(jìn)行了重新“定位”之后，當(dāng)前HttpContext中的一些屬性也就發(fā)生了相應(yīng)的變化（例如HttpContext.Request.Path）。這樣，接下來(lái)的Pipeline事件的處理程序邏輯就會(huì)受到影響。例如在需要根據(jù)目錄進(jìn)行權(quán)限判斷時(shí)，就會(huì)使用“定位”后的路徑，而不是ASP.NET所收到的請(qǐng)求。自然最“顯著”的變化就是對(duì)Handler的選擇，例如上例，我們把請(qǐng)求重新定位至“CustomerList.aspx”文件，這樣ASP.NET引擎就會(huì)選擇*.aspx所對(duì)應(yīng)的System.Web.UI.PageHandlerFactory類對(duì)請(qǐng)求進(jìn)行處理。

復(fù)制代碼代碼如下:

public class Global : System.Web.HttpApplication
{
    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        HttpContext context = HttpContext.Current;

        if (context.Request.Path.Equals("/Customers",
            StringComparison.InvariantCultureIgnoreCase))
        {
            context.RewritePath("~/CustomerList.aspx");
        }
    }
}

　　最后插句提外話，有兩個(gè)概念需要區(qū)分開(kāi)來(lái)，那就是“ASP.NET Pipeline”與“Web Forms”。兩者都是ASP.NET里的重要模型，但是差別還是非常大的：

ASP.NET Pipeline：作為每個(gè)ASP.NET應(yīng)用所接受到的請(qǐng)求來(lái)說(shuō)，都會(huì)經(jīng)過(guò)這個(gè)“管道”進(jìn)行處理。這是一個(gè)ASP.NET級(jí)別的模型。
Web Forms：在ASP.NET Pipeline的執(zhí)行過(guò)程中，其中有一個(gè)步驟是選擇一個(gè)合適的Handler（或HandlerFactory）來(lái)處理請(qǐng)求。如果是aspx頁(yè)面，ASP.NET就會(huì)選擇System.Web.UI.PageHandlerFactory類，在這個(gè)類中才最終形成了WebForms模型。
其實(shí)上面這句話的“形成”二字可能也不太確切。因?yàn)閃eb Forms可能應(yīng)該是一個(gè)可以獨(dú)立使用的執(zhí)行引擎和模型，而System.Web.UI.PageHandlerFactory中也只是利用了這個(gè)模型而已。我們?cè)诰帉?xiě)ASP.NET應(yīng)用時(shí)，完全可以根據(jù)我們的需要，在其他地方使用這個(gè)模型。例如在《技巧：使用User Control做HTML生成》一文中，我們就在一個(gè)Generic Handler中把a(bǔ)scx當(dāng)作模板來(lái)生成內(nèi)容。

您可能感興趣的文章: