ASP.NET MVC路由

對於傳統的ASP.NET Web Form應用來說，使用者請求總是指向某個具體的物理檔案，目標檔案的路徑決定了訪問請求的URL。但是對於ASP.NET MVC應用來說，來自瀏覽器的請求總是指向定義在某個控制器Controller型別中的某個Action動作方法，請求URL與目標Controller/Action之間的對映是通過路由來實現的。

ASP.NET 路由

由於來自客戶端的請求總是指向定義在某個Controller型別中的Action方法，且目標Controller和Action的名稱由請求URL決定，所以必須採用某種機制根據請求URL解析出目標Controller和Action的名稱，這種機制便是路由（Routing）。但路由系統並不專屬於ASP.NET MVC，而是直接建立在ASP.NET上，實際路由的核心型別基本上定義在程式集System.Web.dll中。路由機制同樣可以應用在Web Forms應用中，路由可幫助實現請求地址與物理檔案的分離。

請求URL與物理檔案的分離

對於一個ASP.NET Web Forms應用來說，一個有效的請求對應著一個具體的物理檔案。部署在Web伺服器上的物理檔案可以是靜態的，如圖片或靜態HTML檔案等。 也可以是動態的如.aspx頁面。

對於靜態檔案的請求，ASP.NET會直接返回檔案的原始內容，而針對動態檔案的請求則會涉及相關程式碼的執行。這種將URL與物理檔案緊密捆綁的方式並不是一種很好的解決方案，帶來的侷限性主要體現在：

• 靈活性

物理檔案的路徑決定了訪問它的URL，如果物理檔案路徑發生改變，原本訪問檔案的URL將變得無效。

• 可讀性

URL不僅具備基本的可用性，能夠訪問正確的網路資源，還需具有很好的可讀性。好的URL設計應該有眼看出針對它訪問的目標資源是什麼，請求地址與物理檔案緊密繫結使我們失去了設計高可讀性URL的機會。

• SEO優化

對於網站開發來說，為了迎合搜尋引擎檢索的規則，需對URL進行有效的設計，使之能易於被主流的搜尋引擎檢索收錄。如果URL完全與實體地址關聯，無異於失去了SEO優化的能力。

因此，採用更為靈活的對映機制來實現請求URL與目標路徑的分離。那麼有什麼辦法能夠幫助實現兩者和之間的分離呢？很多人會想到“URL重寫機制”。為了使Web應用可獨立地設計用於訪問應用資源的URL，微軟的IIS7編寫了URL重寫模組，這是一個基於規則的URL重寫引擎，它在URL被Web伺服器處理之前根據定義的規則重定向某個物理檔案。

URL重寫機制在IIS級別解決了URL無實體地址的分離，其實現依賴於一個在註冊到IIS管道上的原生程式碼模組，所以它可以寄存在IIS中的所有Web應用型別。與URL重寫機制不同，路由系統則是ASP.NET的一部分，並通過託管程式碼編寫。