ASP.NET MVC框架中的URL路徑的選擇場景是什么

這篇文章將為大家詳細講解有關ASP.NET MVC框架中的URL路徑的選擇場景是什么，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

ASP.NET MVC框架中的路徑選擇場景：自定義查詢URL

讓我們使用一下現實場景中的自定義路徑選擇規則來對此示范，以實現我們的電子商務網站的查詢功能為例。

開始，我們往我們項目中添加一個新的SearchController類：

然后，我們在SearchController類中定義2個Action方法。Index()方法用來顯示一個查詢網頁，上有一個文本框，讓用戶來輸入和提交查詢文字。Results() action方法則用來處理相應的表單提交，對數據庫做查詢，然后把結果顯示給用戶：

使用默認的/[controller]/[action]/[id] URL路徑映射規則，我們可以現成使用象下面這樣的URL來調用我們的SearchController的行為：

注意，根URL /Search 默認映射到Index() action方法的原因是因為在Visual Studio創建一個新項目時，默認添加的 /[controller]/[action]/[id] 的路徑定義將默認的action自動設置到“Index"上的（通過Defaults屬性）：

雖然象 /Search/Results?query=Beverages 這樣的URL是完全可行的，我們也許決定對查詢結果我們想要稍微好看些的URL。具體來說，我們也許想去掉URL中的“Results”action名稱，把要查詢的文字作為URL的一部分傳入，而不是作為URL的查詢字符串的值。例如：

我們可以通過在默認的 /[controller]/[action]/[id] 規則之前添加2條自定義的URL路徑映射規則來啟用這些比較好看的查詢結果URL，象下面這樣：

在前2條規則中，我們現在明確地指定了對應 /Search/ URL的控制器和Action參數。我們表明，"/Search" 應該總是由SearchController上的“Index” action來處理。而任何擁有子URL層次結構的URL （/Search/Foo, /Search/Bar等等 ）則總是由SearchController上的 "Results" action 來處理。

上面的第二條路徑選擇規則表明，在 /Search/ 前綴之后的任何字符應該當作名為"[query]"的參數來處理，這個參數將作為方法參數來傳入SearchController上的Results action方法中：

最有可能的，我們還會對查詢結果啟用分頁（我們每次只顯示10個查詢結果）顯示。我們可以通過查詢字符串值的方法來實現（譬如，/Search/Beverages?page=2），或者我們也可以把頁號嵌在URL中（譬如/Search/Beverages/2）。要支持后面這個做法的話，我們需要做的是，給我們的第二條路徑選擇規則再加一個額外的可省參數：

注意，上面的新URL規則現在匹配的是“Search/[query]/[page]"。我們還將默認的頁號配置為1，萬一頁號沒有包含在URL之中的話（這是通過作為“Defaults”屬性值的匿名類型傳入的）。

然后我們可以把我們的SearchController.Results action方法更新為接受頁號參數作為一個方法參數：

這樣，我們就有比較好看的查詢URL了。

ASP.NET MVC框架中路徑選擇規則的驗證先決條件

就象我在這個貼子前面提到的，Route類有個Validation屬性，允許你添加為使路徑選擇規則匹配，必須為真的驗證先決條件規則（除了URL過濾外）。asp.net mvc框架允許你使用正則表達式來驗證URL中的參數值，也允許你對HTTP Headers進行評估（根據HTTP動詞的不同進行不同的URL路徑選擇）。

下面是一個我們可以用到象 /Products/Detail/43 這樣的URL身上的自定義的驗證規則，它指定了其中的ID參數必須是數字（不允許字符串），而且它的長度必須在1到8之間：

如果我們往應用中傳入象 /Products/Detail/12 這樣的URL,上面的路徑選擇規則是合法的，但如果傳入 /Products/Detail/abc 或 /Products/Detail/23232323232，它就不會匹配。

關于ASP.NET MVC框架中的URL路徑的選擇場景是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。