ASP.NET MVC路由(二)

 ASP.NET MVC路由(二)

前言

在上一篇中，提及了Route、RouteCollection對(duì)象的一些信息，以及它們的結(jié)構(gòu)所對(duì)應(yīng)的關(guān)系。按照處理流程走下來(lái)還有遺留的疑問(wèn)沒(méi)有解決這個(gè)篇幅就來(lái)講解一下。

URL規(guī)則的生成

Url規(guī)則看名字挺嚇唬人的，其實(shí)就是根據(jù)我們自定義的Url來(lái)解析出一個(gè)模式，然后等待請(qǐng)求的Url來(lái)的時(shí)候，跟我們定義的模式進(jìn)行匹配(如下圖)。這是后續(xù)的內(nèi)容。

在上篇中說(shuō)到URL規(guī)則的定義是在Route對(duì)象中的，下面來(lái)講解在Route對(duì)象***趺錘縈沒(méi)ё⒉岬腢RL轉(zhuǎn)變成URL規(guī)則。

還是用前面的示例來(lái)演示，在前篇中說(shuō)道，在MapRoute方法中的”{control}/{action}/{id}”參數(shù)部分代表著要賦值到Route對(duì)象的Url屬***，也說(shuō)過(guò)在賦值Route對(duì)象的Url屬***時(shí)Set訪問(wèn)器還會(huì)做一些其它的操作。例如代碼1-1：

代碼1-1

 1         public class Route
 2         {
 3             private string _url;
 4             private ParsedRoute _parsedRoute;
 5             public string Url
 6             {
 7                 get { return _url; }
 8                 set
 9                 {
10                     _url = value;
11                     //解析Value值
12                     this._parsedRoute = RouteParser.Parse(value);
13                 }
14             }
15             ……
16         }

這里只是顯示了Route對(duì)象的一部分用于演示，在代碼1-1中，可以看出RouteParser類型負(fù)責(zé)把接收到的Url值轉(zhuǎn)換成ParsedRoute類型的對(duì)象。

這個(gè)ParsedRoute類型的對(duì)象是Route類型的內(nèi)部私有類型，而轉(zhuǎn)換而成的Url模式信息就存放在這個(gè)類型的對(duì)象實(shí)例中。請(qǐng)看圖1：

圖1

圖1所示，當(dāng)一個(gè)Url值為”{controller}/{action}”賦值到Route對(duì)象的Url屬***時(shí)，會(huì)由RouteParser內(nèi)部類型的Parse()靜態(tài)方法來(lái)執(zhí)行Url解析并且轉(zhuǎn)換成ParsedRoute內(nèi)部類型，而ParsedRoute類型的構(gòu)造函數(shù)是由PathSegment類型的集合構(gòu)成。而在MVC框架中并不是使用PathSegment類型的，而是使用PathSegment類型的的派生類（如圖2），并且這些派生類分別對(duì)應(yīng)著不同的Url片段，就好比示例的”{controller}/{action}”就會(huì)分別的表示為兩種類型（下面會(huì)講到）。

圖2

正如圖2所示的對(duì)象模型，按照?qǐng)D2的模型結(jié)構(gòu)。這個(gè)時(shí)候ParsedRoute內(nèi)部所存的Url模式值為圖3所示，

圖3

如圖3所示上述示例中的“controller”生成為ContentPathSegment類型，而“/”則被生成為SeparatorPathSegment類型。對(duì)于這些類型的具體細(xì)節(jié)這里就不做詳細(xì)的介紹了。目的在于只是把內(nèi)部的實(shí)現(xiàn)粗略的把對(duì)象模型說(shuō)明一下，目的就是讓大家知道有這么一個(gè)過(guò)程來(lái)生成URL規(guī)則，并且是什么樣的一個(gè)實(shí)現(xiàn)的方式，讓大家知道Route對(duì)象的本身就是帶有URL規(guī)則的，在服務(wù)器請(qǐng)求到來(lái)的時(shí)候是眾多Route對(duì)象根據(jù)自身攜帶的URL規(guī)則來(lái)進(jìn)行匹配，這部分內(nèi)容后續(xù)說(shuō)到。

如果感興趣想清晰的知道內(nèi)部實(shí)現(xiàn)的具體，可以自己用反編譯工具來(lái)看里面的源代碼，這部分的Url規(guī)則的生成過(guò)程就講到這里。

希望看完后大家能夠記住大概的流程和這些對(duì)象在系統(tǒng)中的位置。會(huì)在下一篇幅講解RouteData的是怎么根據(jù)請(qǐng)求的Url來(lái)匹配生成的。