之前覺得這個話題已經(jīng)被談濫了。URL Rewrite早已經(jīng)被廣大開發(fā)人員所接受,網(wǎng)上關(guān)于URL Rewrite的組件和文章也層出不窮,但是總是讓我感覺意猶未盡,于是最終還是忍不住提筆寫了這系列文章。這些文章不會談?wù)揢RL Rewrite的價值與意義,而只會談?wù)摷兗夹g(shù)的內(nèi)容。文章中也不會有詳盡地實現(xiàn)分析,而是結(jié)合了我的經(jīng)驗,從應(yīng)用角度來講解這個話題。您已經(jīng)知道的,您還不知道的,別處已經(jīng)講過的,或者還沒有講過的,希望這系列文章的“舊事重提”不會讓您覺得沉悶,并且能讓您了解ASP.NET中URL Rewrite的方方面面。如果您以后再遇到URL Rewrite方面的問題是能夠想到這幾篇文章,估計我做夢也會笑出聲來。
要充分理解文章后面談到的話題,我們必須簡單的了解一下IIS與ASP.NET的通信過程。我在這里講解的是IIS 6服務(wù)器。至于IIS 5和IIS 7,前者可以說已經(jīng)被淘汰了,而后者的“經(jīng)典模式”與IIS 6可謂如出一轍,而新的“管道模式”其實是講ASP.NET中的某些概念與IIS進行了深度集成。我相信,如果您了解了IIS 6和ASP.NET,在IIS 7的集成模式下也不會有任何問題。
之所以在BeginRequest中進行Rewrite,是因為這個事件是在所有Pipeline事件中最早被觸發(fā)的。在這時進行了重新“定位”之后,當(dāng)前HttpContext中的一些屬性也就發(fā)生了相應(yīng)的變化(例如HttpContext.Request.Path)。這樣,接下來的Pipeline事件的處理程序邏輯就會受到影響。例如在需要根據(jù)目錄進行權(quán)限判斷時,就會使用“定位”后的路徑,而不是ASP.NET所收到的請求。自然最“顯著”的變化就是對Handler的選擇,例如上例,我們把請求重新定位至“CustomerList.aspx”文件,這樣ASP.NET引擎就會選擇*.aspx所對應(yīng)的System.Web.UI.PageHandlerFactory類對請求進行處理。
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");
}
}
}
ASP.NET Pipeline:作為每個ASP.NET應(yīng)用所接受到的請求來說,都會經(jīng)過這個“管道”進行處理。這是一個ASP.NET級別的模型。
Web Forms:在ASP.NET Pipeline的執(zhí)行過程中,其中有一個步驟是選擇一個合適的Handler(或HandlerFactory)來處理請求。如果是aspx頁面,ASP.NET就會選擇System.Web.UI.PageHandlerFactory類,在這個類中才最終形成了WebForms模型。
其實上面這句話的“形成”二字可能也不太確切。因為Web Forms可能應(yīng)該是一個可以獨立使用的執(zhí)行引擎和模型,而System.Web.UI.PageHandlerFactory中也只是利用了這個模型而已。我們在編寫ASP.NET應(yīng)用時,完全可以根據(jù)我們的需要,在其他地方使用這個模型。例如在《技巧:使用User Control做HTML生成》一文中,我們就在一個Generic Handler中把ascx當(dāng)作模板來生成內(nèi)容。