淺析ASP.NET中Route組件的設(shè)計思考與模式
在這里我們將介紹Route組件，對于這個組件相關(guān)文章不多。經(jīng)過老趙的這一番介紹，希望這些知識能對大家了解Route組件有所幫助。
Route組件雖然可以說是ASP.NET的“門戶”，不過至今為止似乎都被微軟當(dāng)作是二等公民。可能是由于自帶的Route類功能已經(jīng)太強，微軟官方或社區(qū)內(nèi)都不太關(guān)注RouteBase的擴展。不過有一點是正確的，那就是在大部分情況下的確沒有必要去擴展RouteBase。事實上，我構(gòu)建過不少RouteBase類，不過除了DomainRoute之外，其余的都被我放棄了，例如在大半年前寫的《請別埋沒了URL Routing》中所提供的FormatRoute，在MvcPatch中也已經(jīng)有了更好的替代品（過幾天便會談到這一點）。
RouteBase職責(zé)明確：從請求中獲取數(shù)據(jù)，及根據(jù)數(shù)據(jù)生成虛擬路徑。它只有兩個方法：GetRouteData和GetVirtualPath，擴展起來非常容易，各種“模式”均可以體現(xiàn)出來。例如DomainRoute和FormatRoute都是使用了裝飾器模式，在內(nèi)部RouteBase的GetRouteData或GetVirtualPath方法的“前后”再加上一些邏輯（例如DomainRoute中的域名匹配或生成）。有趣的是，在幾個月前我還寫過一個InterceptRoute類：
- public class InterceptRoute : RouteBase
- {
- public InterceptRoute(RouteBase innerRoute, IList
interceptors) - {
- this.InnerRoute = innerRoute;
- this.Interceptors = new InterceptorCollection(interceptors);
- }
- public RouteBase InnerRoute { get; private set; }
- public InterceptorCollection Interceptors { get; private set; }
- ...
- }
在很多時候，能夠像一個組件中插入“橫切”的邏輯總是很有用的（例如昨天剛提的NHibernate Interceptor），而上面這個便是在Route規(guī)則的各方法前后插入各種邏輯。提供這個邏輯的便是IRouteInterceptor對象，它有四個方法：
PreGetRouteData
PostGetRouteData
PreGetVirtualPath
PostGetVirtualPath
從它們的名稱上您也一定可以看得出它們是做什么的。從理論上來說，無論是DomainRoute還是FormatRoute，只要是為現(xiàn)有方法補充前/后置邏輯的擴展，都可以通過提供IRouteInterceptor來實現(xiàn)。不過我除了DomainRoute以外，還真沒發(fā)現(xiàn)其他的使用環(huán)境。這個InterceptRoute似乎也是娛樂價值大于實際價值。因此就在這里一提，等以后忽然發(fā)現(xiàn)真有用了我們再拿出來遛遛。
除了裝飾器模式/InterceptRoute之外，我還曾經(jīng)想過構(gòu)建另一種“結(jié)構(gòu)性”（如InterceptRoute一樣，本身不提供實際用途）的Route擴展，那就是利用了組合模式的Route規(guī)則。利用組合模式，我們可以將多個RouteBase對象聚合起來，并且在GetRouteData或GetVirtualPath的時候?qū)⒙氊?zé)委派給這些對象。事實上，它的職責(zé)就好似Routing框架本身所帶的RouteCollection一樣——當(dāng)然，之前我們也談過，RouteCollection的邏輯并不那么單純。
假設(shè)我們已經(jīng)有了這樣一個CompositeRoute對象收集了一堆Route規(guī)則，那么什么時候會需要這樣的場景呢？其實DomainRoute就可以是這樣的，因為“一個域名下有多個Route規(guī)則”簡直是天經(jīng)地義的事情。但其實事情并沒有那么簡單，個中原因便是我們昨天所談?wù)摰?ldquo;命名問題”。
由于在配置Route規(guī)則的時候，我們要為每個Route提供一個名稱——但是這個名稱只是對RouteCollection才有效果，確切地說，只有RouteTable.Routes這個RouteCollection實例才會用到這一點。如此的話，使用CompositeRoute勢必將原本能夠有名稱的多個Route規(guī)則捆綁在了一起，我們在生成URL的時候就無法通過名稱定位到特定的Route上了。
由于RouteCollection中釋放接口有限（也不是開源的，這意味著我們無法改造它），這一點幾乎無法通過自定義邏輯的方式來改進。因此在我看來，CompositeRoute幾乎無法用在任何場景上——DomainRoute當(dāng)然也不會使用這種設(shè)計方式了。
原文標(biāo)題：淺談Route組件的設(shè)計思考與模式
鏈接：http://www.cnblogs.com/JeffreyZhao/archive/2009/10/14/aspnet-routing-design-ideas-and-patterns.html
【編輯推薦】
- ASP.NET MVC單元測試：HttpContext類的Path屬性解惑
- 自定義的ControllerFactory：接口實現(xiàn)，支持Area
- ASP.NET Routing之“解析URL”功能詳解
- 為ASP.NET MVC應(yīng)用添加自定義路由
- 學(xué)習(xí)ASP.NET MVC路由的使用方法
