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路径的选择场景是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。