ASP.NET MVC框架中的URL路径选择场景

ASP.NET MVC框架中的URL路径选择场景

2009-07-24 11:20 scottgu blog.joycode 字号：T | T

本文深入讨论asp.net mvc框架的路径选择（routing）架构及一些定制方式，可以将其用于应用中的一些更高级的场景。

AD：51CTO 网+ 第十二期沙龙：大话数据之美_如何用数据驱动用户体验

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路径选择场景。