Microsoft .NET Framework 3.5 Service Pack 1 在 ASP.NET 運行時中引入了路由引擎。路由引擎可以從響應傳入 HTTP 請求的實際 Web 窗體中分離該請求中的 URL，使您能夠為 Web 應用程序構建友好的 URL。盡管在以前版本的 ASP.NET 中也一直都能夠使用友好的 URL，但路由引擎卻提供了一種更簡單、更明晰和更容易測試的方法。
路由引擎最初是 ASP.NET 模型視圖控制器 (MVC) 框架的一部分，在撰寫本文時它仍處於預演階段。但是，Microsoft 將路由邏輯封裝到了 System.Web.Routing 程序集中，並隨同 SP1 發布了該程序集。目前該程序集使用 ASP.NET 動態數據功能（它們也隨 SP1 一起發布）為網站提供路由，但在本專欄中，我將介紹如何通過 ASP.NET Web 窗體來使用路由功能。
什麼是路由？
假設您有一個名為 RecipeDisplay.aspx 的 ASP.NET Web 窗體，此窗體位於一個名為 Web Forms 的文件夾中。使用此 Web 窗體查看方案時，傳統方法是構建一個指向該窗體實際位置的 URL，並將某些數據通過編碼方式嵌入到查詢字符串中，以告知 Web 窗體要顯示的方案。此類 URL 的結尾可能如下所示：/WebForms/RecipeDisplay.aspx?id=5，其中數字 5 代表在一個充滿方案的數據庫表中的主鍵值。
路由從本質上來說就是把一個 URL 端點分解成多個參數，然後使用這些參數將 HTTP 請求處理引導至特定的組件。讓我們以 URL /recipe/5 為例。借助正確的路由配置，您仍可以使用 Web 窗體 RecipeDisplay.aspx 來響應此 URL。
此時 URL 不再代表實際的路徑。單詞 recipe 變為代表一個參數，路由引擎可以用它找到處理 recipe 請求的組件。數字 5 代表第二個參數，在處理期間用它顯示某個特定的 recipe。此時不宜通過編碼將數據庫關鍵字嵌入 URL 中，更好的做法是使用形如 /recipe/tacos 的 URL。此 URL 不但包括足夠多的參數來顯示特定的 recipe，還非常便於人們閱讀理解，它可以為最終用戶揭示其意圖，並包括一些重要的關鍵字供搜索引擎使用。
URL 重寫的簡史
在 ASP.NET 中，使用以 /recipe/tacos 結尾的 URL 時，從傳統上而言需要有人來處理 URL 重寫架構。有關 URL 重寫的詳細信息，請參閱 Scott Mitchell 撰寫的權威文章“在 ASP.NET 中執行 URL 重寫”。該文描述了在 ASP.NET 中使用 HTTP 模塊和 HttpContext 類的靜態 RewritePath 方法重寫 URL 的常見途徑。Scott 的文章還詳細說明了友好且可改動 URL 的優點。
在過去曾使用過 RewritePath API 的用戶可能非常清楚重寫方法中的某些怪異現象和缺點。RewritePath 面臨的主要問題是在處理請求的過程中該方法如何更改所使用的虛擬路徑。使用 URL 重寫時，需要設定每個 Web 窗體的回發目標（通常通過在請求過程中再次重寫 URL 來實現），以避免回發轉到內部已重寫的 URL。
此外，大多數開發人員在實現 URL 重寫時都采用單向轉換模式，因為無法通過任何簡單的機制使 URL 重寫邏輯雙向工作。例如，要賦予 URL 重寫邏輯一個面向公眾的 URL 並使該邏輯返回 Web 窗體的內部 URL 非常容易。但是，要為 Web 窗體的內部 URL 賦予重寫邏輯並使其返回進入窗體所需的公共 URL 卻很困難。生成到隱藏在被重寫的 URL 中的其他 Web 窗體的超鏈接時，後者會非常有用。本專欄的其余部分介紹了 URL 路由引擎如何解決這些問題。
圖 1 路由、路由處理程序和路由模塊
