《Pro ASP.NET MVC 3 Framework》学习笔记之十八【URL和Routing】

简介:

整个项目范围的依赖注入(Project-Wide Dependency Injection)

在书接下来的章节里面,我们会看到MVC框架提供的很多不同的方式来让我们扩展和自定义对请求的处理,每一种方式都会用一个实现的接口或一个派生的基类来定义。

在第一部分的SportsStore项目实例里面已经有过引入。我们从DefaultControllerFactory类派生了一个NinjectControllerFactory类,以至于我们能够创建Controller,并使用Ninject来管理DI(依赖注入)。如果使用这种方法针对MVC里面每一个自定义的点,最终会让我们将DI贯彻到整个应用程序,但是这样会复制很多代码,会有比我们想象得多的Ninject kernel。

当MVC框架需要创建一个类的实例时,它会调用System.Web.Mvc.DependencyResolver类的一个静态方法。我们可以通过实现IDependencyResolver接口并使用DependencyResolver注册我们的实现来达到将DI贯彻整个应用程序的效果。这样做以后,无论MVC框架什么时候需要创建一个类的实例,它都会调用我们定义的类,我们就可以调用Ninject来创建对象。

下面的代码展示了在SportsStore里面如何实现IDependencyResolver接口,如下:

View Code

上面的类里面,当MVC请求一个新的类的实例的时候会调用开始的两个方法,经历这样的请求也会很简单的调用Ninject kernel。我们添加了一个用来绑定来自类外面绑定的方法AddBindings()方法。接着注册IDependencyResolver接口实现,如下所示:

View Code

所有这些修改让我们将Ninject放在了MVC非常核心的位置上,我们仍然能够利用MVC扩展性强的优势。但是如果我们要做的全部就是在请求管2道的一些部分引入DI的话,我们就不用再做了,因为前面已经完成了,呵呵。

接下来的笔记主要是关于URL和Routing的(非常重要的,webform里面是基于事件驱动的,MVC里面是基于URL驱动的)

在WebFrom里面我们知道,在请求的URL和服务器磁盘上的文件是有直接的对应关系的,要是没有这种关系,通常都会报404错误。而在MVC里面是没有这种一对一的对应关系的,URL请求都是通过Controller里面的Action方法来处理的。为了处理MVC的URL,asp.net平台使用了routing system,路由系统不是MVC特有的,而是asp.net平台的功能,也就是说在WebFrom里面也是存在路由系统的。routing system的类包含在了System.Web命名空间下,从这里也可以看出它不是MVC特有的。

MVC的Routing System(路由系统)具有两个功能:

1.检查传入的URL,并计算出该请求需要的Controller和Action 
2.创建输出的URL,这些URL是在从View呈现的html里面出现的,为了能够在用户点击一个URL时能调用一个具体的Action(当用户点击时又变成一个传入的URL了)

下面创建一个MVC3的项目UrlsAndRoutes来具体说明MVC里面的routing。

这次我们选择Internet Application Template,它会帮我们生成一个实例程序,方便我们学习。MVC里面的路由定义在Global.asax.cs里面

View Code

Application_Start()方法在程序第一次启动时被底层的asp.net平台调用,进而导致RegisterRoutes方法也会被调用。方法的参数是一个静态属性RouteTable.Routes,它是RouteCollection类的一个实例。

这里我们可以先删除在RegisterRoutes里面生成的默认的路由值,在此之前,我们要先了解下对routing system非常重要的东西:

URL模式(URL patterns)

routing system一个不可思议的地方是它使用了一套routes,这些routes组合构成一个应用程序的URL架构或模式,这些URL模式是程序将要识别和响应的。每一个路由包含一个URL模式,将它跟请求过来的URL进行比较。如果能够匹配,routing system就会用它来处理这个URL。

URL可以分割为几个不同的段(Segment)(不包含主机名和query string),通过"/"分隔,例如下面的一个URL。

分隔的第一个小段是Admin,第二个是Index。

我们能够看出这个对应了Controller和Action,但是我们需要把这种对应关系表达为routing system能够理解的形式,也就是URL模式(URL pattern)。这里的URL模式就是{controller}/{action}。

当处理请求URL时,routing system的工作就是匹配该URL到一个URL模式并提取在模式里面定义的segment变量的值(segment变量就是这里的controller和action,它们对应的值分别是Admin和Index)。

Note:routing system没有任何关于controller和action的特别的知识点,仅仅是当请求到达MVC框架本身时提取segment变量的值并在请求管道(request pipeline)中传递,这意味着会给controller和action变量赋值。这也就是为什么routing system能够在WebFrom里面使用以及我们如何能够自定义变量。

默认情况下,一个URL模式会匹配任何一个跟它具有相同segment数量的URL。例如{controller}/{action}会匹配如下URL

图中高亮的部分说明了URL模式的两个关键的行为:

1.URL模式是保守的:只匹配具有同等segment数量的URL  

2.URL模式同时又是开放的:只有segment数量相等,不过具体的是什么,都能够提取segment变量对应的值。

前面有提到过,routing system是独立于MVC的,对MVC应用程序没有任何了解。所以,当没有对应的controller和action能够对从URLsegment变量提取的值进行响应的时候,URL模式仍会进行匹配。

上图中的第二种情况,就是把Admin和Index颠倒了,也能够提取值,只不过提取出来的值也是颠倒的。这里并没有一个Index的controller和Admin的Action。

下面创建一个简单的route,代码如下:

View Code

我们创建了一个新的route对象,并将URL模式作为一个构造器参数传递,同时还传递了一个MvcRouteHandler的实例参数。不同的ASP.NET技术提供不同的类来处理路由的行为,MvcRouteHandler类是MVC里面使用的类。一旦创建了一个路由(Route),可以使用Add方法添加到RouteCollection对象里面,同时可以给我们创建的路由传递一个名字。在Add方法里面传递路由的名字是可选的,也可以为空。这里使用的是Add方法将定义的路由注册到RouteCollection里面,还有一种更加简便的方式就是使用MapRoute方法。如下所示:

View Code

这个方法更加精简,主要是因为不需要创建MvcRouteHandler类的实例。MapRoute仅仅是MVC使用的,在ASP.NET WebFrom里面使用的是MapPageRoute(也是定义在RouteCollection里面的)

要对routes进行单元测试,需要mock三个类 HttpRequestBase,  HttpContextBase, 和HttpResponseBase。为了方便测试,我们创建几个通用的方法如下:

View Code

下面是一个测试路由的例子:

View Code

测试里面有两个方法TestRouteMatch和TestRouteFail,TestRouteMatch确保URL正确的格式以及能够使用URL segments取到controller和action恰当的值;TestRouteFail确保我们的程序不接受不匹配URL模式的URL。测试时,在URL前面加上了"~"的前缀。因为ASP.NET框架就是这样将URL呈现给routing system的。

如果我们运行程序会报404错误,因为直接运行时,地址栏里面的URL是http://localhost:<port>/ ,而我们没有创建针对该URL的路由。当我们输入URL:http://localhost:<port>/Home/Index就可以看到示例效果了。

这里URL模式处理URL并提取Home这个controller变量的值和Index这个action变量的值(Home和Index就是segment变量)

定义默认值

在上面我们第一次运行程序的时候报了404错误,是因为"~/"没有匹配我们定义的URL模式{controller}/{action}。一种解决的方式就是定义默认值,当URL里面不包含要匹配的segment时,默认值就被使用了。把路由做如下更改:

View Code

默认值是作为一个匿名类型的属性提供的,上面的我们提供了action变量Index的默认值。这时路由就可以匹配两种URL了:

1.http://localhost:<port>/Home/Index;2.http://localhost:<port>/Home.

第一种不必说当然可以,因为我们定义action变量的默认值所以当URL里面没有action这个segment时,我们定义的默认值就被使用了。

我们进一步提供默认值,修改如下:

View Code

我们提供了两个默认值,这个时候运行程序就不会报错了。因为此时"http://localhost:<port>/"里面既没有controller这个segment,也没有action这个segment。但是我们定义的它们的默认值会被使用。这个路由可以匹配的URL如下所示:

可以做如下测试:

View Code

使用静态的URL Segment

并不是在一个URL模式里面所有的segments都需要是变量。也可以定义不变的segment,即静态segment。
假设我们需要匹配这样一个URL:http://mydomain.com/Public/Home/Index 。可以添加一个路由如下:

复制代码
public static void RegisterRoutes(RouteCollection routes) 
{
routes.MapRoute("MyRoute", "{controller}/{action}",
new { controller = "Home", action = "Index" });

routes.MapRoute("", "Public/{controller}/{action}",
new { controller = "Home", action = "Index" });
}
复制代码

Public/{controller}/{action}匹配包含3个segment的URL,第一个必须是Public.也可以创建一个具有静态元素也有变量的segment的URL模式.如下所示:

复制代码
public static void RegisterRoutes(RouteCollection routes) 
{
routes.MapRoute("", "X{controller}/{action}");
routes.MapRoute("MyRoute", "{controller}/{action}",
new { controller = "Home", action = "Index" });
routes.MapRoute("", "Public/{controller}/{action}",
new { controller = "Home", action = "Index" });
}
复制代码

如果http://mydomain.com/XHome/Index,而取第一个segment变量的值是不会包含X的,仍然取的是Home而不是XHome

Route排序

当使用MapRoute方法添加routes时,被使用的顺序一般情况下是按照它在RouteCollection对象里面出现的顺序。之所以这里说"一般情况",是因为有方法能够让我们选择插入的位置,但是不提倡这样做,因为直接使用MapRoute插入route是按照它们被定义的顺序,这样更容易理解程序的路由。路由系统通过URL模式匹配请求的URL,并且在当前路由不匹配的情况下才处理下一个路由,会一直匹配到最后一个路由为止。这样的结果就要求我们必须按照从具体到抽象的顺序来排列路由,这里类似于我们处理异常的顺序。如果我们将上面的路由排列顺序做如下改动:

复制代码
public static void RegisterRoutes(RouteCollection routes) 
{

routes.MapRoute("MyRoute", "{controller}/{action}",
new { controller = "Home", action = "Index" });

routes.MapRoute("", "X{controller}/{action}");

routes.MapRoute("", "Public/{controller}/{action}",
new { controller = "Home", action = "Index" });
}
复制代码

因为第一个路由会匹配具有0,1,2个segment的URL,其实也就是全部的情况了。这个时候运行程序输入:http://mydomain.com/XHome/Index,程序会报404错误。

我们能够联合静态URL和默认值来创建一个具体URL的别名,这会在需要公开的发布我们的URL架构并且与用户制定了一个契约时非常有用。如果我们在这种情形下重构一个应用程序,我们需要保护之前的URL格式。让我们设想这样一个场景:我们有一个ShopController,现在被HomeController代替,下面的代码展示如何保护老的URL架构:

View Code

这个路由可以匹配以Shop为第一个segment并包含两个segment的URL。该URL模式没有包含一个controller的segment变量,所以这里的默认值会被使用。这意味着对ShopController里面Action请求转换成了对HomeController里面的Action请求。

我们可以进一步深入,为我们要重构的Action方法创建一个别名并且不用在呈现controller了,达到这样的效果只需要我们提供controller和action的默认值就可以了。如下:

复制代码
public static void RegisterRoutes(RouteCollection routes) 
{

routes.MapRoute("ShopSchema2", "Shop/OldAction",
new { controller = "Home", action = "Index" });

routes.MapRoute("ShopSchema", "Shop/{action}", new { controller = "Home" });
其他路由...
}
复制代码

这时我们只需要输入http://localhost:port/Shop就行了,输入Shop/OldAction是会报404的。

自定义segment变量

MVC里面不是只能定义controller和action两个segment变量,我可以定义自己的segment变量,如下所示:

View Code

上面的路由定义了一个id的segment变量,可以匹配0-3个segment的URL。对于我们自己定义segment变量时,变量名不能是controller,action,area。
我们可以使用RouteData.Values访问任何segment变量,这里我们添加一个CustomVariable的方法到HomeController里面,如下所示:

View Code

添加一个视图CustomVariable.cshtml将id的值显示出来,如下:

View Code

下面是针对上面路由的单元测试,如下:

View Code

使用自定义的变量作为Action方法的参数

使用RouteData.Values访问自定义的segment变量的值仅仅是一种方式,有更加优雅的方式来访问segment变量的值。如果我们在Action里面定义参数匹配URL模式的变量,MVC框架会将从URL获取的值作为参数传递给action方法。修改CustomVariable action方法以至于它有一个匹配的参数,如下:

View Code

运行程序输入http://localhost:<port>/Home/CustomVariable/page_1/d   会显示id的值page_1.

当然也可以在路由里面定义多个segment参数,同样也在action方法里面定义多个同样的参数,这时就可以取多个自定义的segment变量的值。自定义的segment变量与action方法的参数要保持一样。

上面定义的id参数是一个字符串的类型,但是MVC框架会试图将URL值转换为任何我们定义在action方法里面的参数类型。如果我们这里定义id为Datetime类型,这时从URL传过来的就是Datetime类型。

下面修改路由增加一个segment变量为flag,并且修改action方法参数如下:

复制代码
        //修改路由  可能有些参数的作用前面还没有介绍,不用急,后面会有说明。
routes.MapRoute("AddContollerRoute", "{controller}/{action}/{id}/{flag}/{*catchall}",
new
{ controller = "Home", action = "Index", id = UrlParameter.Optional }, new[] { "AdditionalControllers" });//这个地方要改成你自己对应的,我这里用的不是
URLsAndRoutes.Controllers。这里后面有介绍的
        public ViewResult CustomVariable(string id, DateTime flag)
        {
            ViewBag.CustomVariable = "id的值为:"+id +"——"+"flag的值为:"+ flag.ToString();
            return View();
        }  
复制代码

运行程序如下图所示:

注意:如果这里的flag不能被转换为DateTime,则会报如下错误:

MVC框架使用模型绑定系统(model binding system)将URL里面包含的指转换为.NET类型。并且可以处理比上面例子里面更加复杂的情形,这一部分在书里面的后面章节会介绍。

在上面定义路由时会有id = UrlParameter.Optional。这个表示该URL中的id segment变量是可选的。关于匹配情况如下所示:

从上面的图可以看出,当URL里面有了对应id的segment时,id就有了相应的值。当没有相应的URL segment来对应id时,并不是表示值为null,而是没有定义。

当你需要知道用户是否提供了一个值时,这点就非常有用。当我们给action里面的参数id提供一个默认值时,我们就不能分别是默认值使用了还是用户输入的URL本身就恰好包含了默认值。

对应测试的代码如下:

View Code

前面的URL模式里面有包含/{*catchall}。以"*"开始的segment,这意味着{controller}/{action}/{id}/{flag}/后面可以匹配多个segment。

对于{controller}/{action}/{id}/{*catchall}(这里不一定要写成catchall,其他的以*开始也OK)可以匹配的情况,如下图所示:

对于*catchall的segment的数量是没有上限的。对应的单元测试如下:

View Code

定义优先使用的Controller所属的命名空间

在上面有定义路由时,有这样一个参数new[] { "AdditionalControllers" },AdditionalControllers是另外建的一个类库里面添加了一个HomeController。所以要添加一个这样的参数,是因为当有几个HomeController分别属于不同的命名空间。这个时候如果不指定一个优先的命名空间,就会抛异常。你可以添加一个AdditionalControllers类库项目,然后添加一个HomeController类,代码如下:

View Code

当一个传入的URL匹配了一个路由,MVC框架会取controller变量的值并寻找合适的controller。例如:当controller变量的值是Home,MVC就会寻找名为HomeController的Controller。这是一个没有限制的类名,当有两个或以上的HomeController时,MVC是不知道怎么处理的,会报错。

这种在大的MVC项目里面发生的概率会大些,所以这就有必要指定一个优先的Controller。具体的使用在上面的定义的路由里面已经有了,定义一个路由如下:

View Code

我们将命名空间表达成一个字符串数组,在上面的代码里面,我们告诉MVC框架首先在URLsAndRoutes.Controllers里面寻找,如果没有找到合适的,则会在其他的命名空间里面寻找。所有添加到这个字符串数组里面的命名空间具有相同的优先级,也就是说不会因为URLsAndRoutes.Controllers在new[] { "URLsAndRoutes.Controllers", "AdditionalControllers"}的最前面而具有更高的优先级。

这样定义以后运行程序仍然会报错的,因为面对两个同名的同优先级的Controller,MVC是不知道怎么处理的。

那我们想要倾向性的使用一个命名空间中的Controller要怎么做呢?使用多个routes,如下所示:

View Code

在后面的章节会介绍如何对整个应用程序设置命名空间的优先级。

我们能够告诉MVC框架仅仅在指定的命名空间寻找,如果没有找到匹配的也不去其他的命名空间寻找。只需要添加一个属性值,如下所示:

复制代码
public static void RegisterRoutes(RouteCollection routes) 
{
Route myRoute = routes.MapRoute("AddContollerRoute", "Home/{action}/{id}/{*catchall}",
new { controller = "Home", action = "Index", id = UrlParameter.Optional },
new[] { "AdditionalControllers" });

myRoute.DataTokens["UseNamespaceFallback"] = false;
}
复制代码

使用正则表达式约束路由(Constraining Routes)

复制代码
public static void RegisterRoutes(RouteCollection routes) 
{
routes.MapRoute("MyRoute", "{controller}/{action}/{id}/{*catchall}",
new { controller = "Home", action = "Index", id = UrlParameter.Optional },
new { controller = "^H.*"},
new[] { "URLsAndRoutes.Controllers"});
}
复制代码

我们通过传递给MapRoute方法一个参数来定义约束,也是一个匿名类型的。要约束的变量跟URL模式里面的segment变量保持一致。上面的路由对controller变量进行约束,必须是H开头的(当然,如果你跟我一样对正则不熟悉,那就去找相关的资料学习下,至少能够明白本书里面的所有正则表达式的含义)。默认值会在约束检查之前被使用。

将约束定义为具体的值:new { controller = "^H.*", action = "^Index$|^About$"}意思是:路由的controller要以H开头,并且action是Index或About。
使用HTTP方法约束:new { controller = "^H.*", action = "Index|About", httpMethod = new HttpMethodConstraint("GET") },这里是不是httpMethod不重要,只要我们实例化HttpMethodConstraint("")并赋值给一个变量(自定义,这里是httpMethod).

注意:这里的约束HTTP方法与在Action方法上面添加特性HttpGet和HttpPost是没有关联的。对路由的限制比在Action上面添加HttpGet和HttpPost限制会在请求管道(request pipeline)的更早的时候被处理。对处理不同的HTTP方法会在后面的章节详细介绍的。我们也可以添加几个HTTP方法如:httpMethod = new HttpMethodConstraint("GET", "POST") }。

对应的单元测试如下:

View Code

自定义约束

如果标准的约束不能满足我们的需求,可以自己实现约束,必须继承IRouteConstraint接口。下面的示例实现了对游览器的约束,当然实际情况不提倡限制浏览器的。这里仅仅为了说明功能。代码如下:

View Code

IRouteConstraint接口定义了一个Match方法,用来实现路由系统的约束是否被满足。如下:

View Code

路由文件请求

不是所有的请求都是针对controller的action的,我也需要提供对images,静态HTML文件,javascript库等的服务。为了说明,先创建一个 StaticContent.html文件。
代码如下:

View Code

输入http://localhost:<port>/Content/StaticContent.html可以访问.默认情况下:路由系统会先检查URL是否匹配具体的文件,不是匹配路由。如果有匹配的,则不会进行路由匹配。如果我们要颠倒这个顺序,可以使用routes.RouteExistingFiles = true(这里有个约定:必须放在方法体的最上面)。接着就可以为具体的文件路径定义路由了,如下所示:

View Code

此时运行系统输入:http://localhost:<port>/Content/StaticContent.html,会显示登录界面。因为优先使用了路由而不会去匹配URL里面的路径。
启用这个属性要慎重,以为很可能导致异常。一般情况下不要启用。现在添加一个OtherStaticContent.html,定义如下路由:

View Code

运行程序,请求http://localhost:<port>/Content/OtherStaticContent.html就会报404.这样做是为了说明:当我们开启了routes.RouteExistingFiles = true属性,优先匹配的是文件路径而不是URL,当文件路径不匹配时(显然现在请求的是OtherStaticContent.html,跟路由里定义的routes.MapRoute("DiskFile", "Content/StaticContent.html"...是不匹配的,所以报404错误)

绕过路由

要忽略对某些文件的路由可以使用routes.IgnoreRoute,如下所示:

View Code

IgnoreRoute方法创建了一个通路,让处理路由的实例是StopRoutingHandler类的而不是MvcRouteHandler的。当一个URL模式经过IgnoreRoute并匹配上,那后面的路由就不会进行匹配了或者说是评估。

好了,今天的笔记到这里,内容比较多,希望对跟我一样的同学有点帮助。
晚安!

本文转自Rt-张雪飞博客园博客,原文链接http://www.cnblogs.com/mszhangxuefei/archive/2012/02/06/mvcnotes_18.html如需转载请自行联系原作者


张雪飞

相关文章
|
4月前
|
开发框架 前端开发 .NET
Asp.net Webapi 的 Post 方法不能把参数加到 URL 中?试试这样写
Asp.net Webapi 的 Post 方法不能把参数加到 URL 中?试试这样写
|
前端开发
前端学习笔记202305学习笔记第三十一天-什么是mvc-前端路由解析和渲染4
前端学习笔记202305学习笔记第三十一天-什么是mvc-前端路由解析和渲染4
54 0
|
7月前
|
JSON 前端开发 Java
Spring mvc-文件上传与JSON-学习笔记
Spring mvc-文件上传与JSON-学习笔记
74 2
|
7月前
|
前端开发 Java 数据库连接
【1024程序员节】RestFul,mvc拦截器,SSM基本整合-学习笔记
【1024程序员节】RestFul,mvc拦截器,SSM基本整合-学习笔记
75 1
|
开发框架 前端开发 .NET
ASP.NET Core 核心特性学习笔记「下」
ASP.NET Core 核心特性学习笔记「下」
|
开发框架 前端开发 中间件
ASP.NET Core 核心特性学习笔记「上」
ASP.NET Core 核心特性学习笔记「上」
|
前端开发
前端学习笔记202305学习笔记第三十天-什么是mvc-m层的创建和数据展示
前端学习笔记202305学习笔记第三十天-什么是mvc-m层的创建和数据展示
56 0
|
前端开发 API
前端学习笔记202305学习笔记第三十天-什么是mvc-c层api 前后端联动1
前端学习笔记202305学习笔记第三十天-什么是mvc-c层api 前后端联动1
75 0
|
前端开发
前端学习笔记202305学习笔记第二十九天-什么是mvc-m层的创建和数据展示1
前端学习笔记202305学习笔记第二十九天-什么是mvc-m层的创建和数据展示1
36 0
|
前端开发 API
前端学习笔记202305学习笔记第三十一天-什么是mvc-c层api 前后端联动3
前端学习笔记202305学习笔记第三十一天-什么是mvc-c层api 前后端联动3
55 0