ASP.NETRouting之“解析URL”功能详解

经常看我博客的人可能会知道，我是一个喜欢搞点小技巧来实现某个功能的人。例如博客的皮肤，自己花了不少时间定义，也是为了效果丰富一些。当然，搞得最多的是从框架或类库内部取出一点小功能来用用，节省自己开发的时间。这其实也是一种复用，尤其是开发一些“扩展”的时候，例如当时尝试为UpdatePanel增加上传功能，虽然最后的结果不是很理想，但是大部分的Hack以及前后端的交互是非常成功的（最大的问题在于跨浏览器实现iframe通信）。而现在也打算总结一次这方面的简单技巧，为以后的文章贡献点引用资源。

创新互联建站是专业的朗县网站建设公司，朗县接单;提供成都网站设计、网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行朗县网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!

ASP.NET Routing中解析URL功能介绍与实现

这次我们想“复用”的内容是ASP.NET URL Routing中“解析URL”的功能。具体一点地说，就是把一个字符串根据指定的Pattern拆分成键/值对的功能。从.NET Reflector反编译System.Web.Routing.dll的结果来看，这部分的解析工作是交由RouteParser和ParsedRoute两个类完成的。这里引用一下相关的使用代码，如果您感兴趣的话，也可以阅读它们完整的实现：

 
 
 

  
  
  
public class Route 
  
  
  
{ 
  
  
  
    public string Url 
  
  
  
    { 
  
  
  
        get { ... } 
  
  
  
        set
  
  
  
        { 
  
  
  
            this._parsedRoute = RouteParser.Parse(value); 
  
  
  
            this._url = value; 
  
  
  
        } 
  
  
  
    } 
  
  
  

  
  
  
    public override RouteData GetRouteData(HttpContextBase httpContext) 
  
  
  
    { 
  
  
  
        string virtualPath = ... 
  
  
  
        RouteValueDictionary values = this._parsedRoute.Match(virtualPath, this.Defaults); 
  
  
  

  
  
  
        ... 
  
  
  
    } 
  
  
  

  
  
  
    ... 
  
  
  
} 
 
 
 

从代码中可以看出，RouteParser的作用是将一个Pattern（如"{controller}/{action}/{id}"）转化成一个“解析器”，而这个解析器便是ParsedRoute类。在需要拆分一个URL字符串（如"Home/Index/5"）的时候，便会调用ParsedRoute类的Match方法，由此得到一个RouteValueDictionary对象，其中包含了Pattern中定义的名称，和一些值的映射关系。

可能您也能够轻易实现这样的功能，不过既然微软已经帮我们做好了，我们也不妨直接使用一下，偶尔用来拆拆字符串也是挺方便的。只可惜RouteParser和ParsedRoute都是由internal修饰的，我们无法直接访问到。那么就用点小技巧吧……说实话，其实您会发现也就这么一回事，“反射”罢了。因此，我们便学着ASP.NET Routing的做法，构建两个类吧：

解析URL的两个类

 
 
 

  
  
  
internal static class RouteParser 
  
  
  
{ 
  
  
  
    public static ParsedRoute Parse(string routeUrl) { ... } 
  
  
  
} 
  
  
  

  
  
  
internal class ParsedRoute 
  
  
  
{ 
  
  
  
    public RouteValueDictionary Match(string virtualPath, RouteValueDictionary defaultValues) { ... } 
  
  
  
} 
  
  
  

 
 
 

我们目前的做法算是一种Hack，为了保证其可维护性，我会选择与目标类库/框架的接口尽可能完全一致的做法。这么做的好处在于，我可以很轻易地理解正在实现的功能，一旦出现了任何问题，就可以直接去找对应的内部实现，而不用在一堆堆的反射关系中“翱翔”。

接着便可以实现我们需要的效果了。在这里，我使用了FastReflectionLib来加快反射调用的性能。虽然我不是一个追求性能极致的Geek，但是如果有一种几乎不耗费额外代价，就能得到数百倍的性能提升，何乐而不为呢？

 
 
 

  
  
  
internal static class RouteParser 
  
  
  
{ 
  
  
  
    private static MethodInvoker s_parseInvoker; 
  
  
  

  
  
  
    static RouteParser() 
  
  
  
    { 
  
  
  
        var parserType = typeof(Route).Assembly.GetType("System.Web.Routing.RouteParser"); 
  
  
  
        var parseMethod = parserType.GetMethod("Parse", BindingFlags.Static | BindingFlags.Public); 
  
  
  
        s_parseInvoker = new MethodInvoker(parseMethod); 
  
  
  
    } 
  
  
  

  
  
  
    public static ParsedRoute Parse(string routeUrl) 
  
  
  
    {  
  
  
  
        return new ParsedRoute(s_parseInvoker.Invoke(null, routeUrl)); 
  
  
  
    } 
  
  
  
} 
  
  
  

  
  
  
internal class ParsedRoute 
  
  
  
{ 
  
  
  
    private static MethodInvoker s_matchInvoker; 
  
  
  

  
  
  
    static ParsedRoute() 
  
  
  
    { 
  
  
  
        var routeType = typeof(Route).Assembly.GetType("System.Web.Routing.ParsedRoute"); 
  
  
  
        var matchMethod = routeType.GetMethod("Match", BindingFlags.Instance | BindingFlags.Public); 
  
  
  
        s_matchInvoker = new MethodInvoker(matchMethod); 
  
  
  
    } 
  
  
  

  
  
  
    private object m_instance; 
  
  
  

  
  
  
    public ParsedRoute(object instance) 
  
  
  
    { 
  
  
  
        this.m_instance = instance; 
  
  
  
    } 
  
  
  

  
  
  
    public RouteValueDictionary Match(string virtualPath, RouteValueDictionary defaultValues) 
  
  
  
    { 
  
  
  
        return (RouteValueDictionary)s_matchInvoker.Invoke(this.m_instance, virtualPath, defaultValues); 
  
  
  
    } 
  
  
  
} 
 
 
 

两个类其实都是使用反射，从类库中获取合适的MethodInfo，然后交给MethodInvoker去执行。其他的……由于代码过于简单，我都不知道还需要解释什么东西。最后就使用xUnit测试一下吧：

解析URL效果测试

 
 
 

  
  
  
public class ParseRouteTest 
  
  
  
{ 
  
  
  
    [Fact] 
  
  
  
    public void Basic_Parsing() 
  
  
  
    { 
  
  
  
        var parsedRoute = RouteParser.Parse("{controller}/{action}/{id}"); 
  
  
  
        var values = parsedRoute.Match("Home/Index/5", null); 
  
  
  
        Assert.Equal("Home", values["controller"]); 
  
  
  
        Assert.Equal("Index", values["action"]); 
  
  
  
        Assert.Equal("5", values["id"]); 
  
  
  
    } 
  
  
  
} 
 
 
 

说实话，这个方法并没有太多技术含量，由于我们将自己的实现和目标实现完全对应起来，所以我们所要做的，似乎也都是些机械的“映射”功能而已。这就引发了我的一个想法，既然很“机械”，那么为什么不去让它“自动”完成呢？例如，我们完全可以写一个类库，来实现这样的效果：

 
 
 

  
  
  
[Type("System.Web.Routing.ParsedRoute, ...")] 
  
  
  
interface IParsedRoute 
  
  
  
{ 
  
  
  
    RouteValueDictionary Match(string virtualPath, RouteValueDictionary defaultValues); 
  
  
  
} 
  
  
  

  
  
  
[Type("System.Web.Routing.RouteParser, ...")] 
  
  
  
interface IRouteParser 
  
  
  
{ 
  
  
  
    [Static] 
  
  
  
    IParsedRoute Parse(string url); 
  
  
  
} 
 
 
 

通过定义接口和标记，我们可以直接“声明”需要“挖掘”出来的类型是什么。然后自然可以有框架为我们进行匹配：

 
 
 

  
  
  
IRouteParser parser = HackFactory.Create(); 
  
  
  
IParsedRoute route = parser.Parse("{controller}/{action}/{id}"); 
  
  
  
RouteValueDictionary values = route.Match("Home/Index/5", null);
 
 
 

是不是一下子变得爽快了许多？简单想了想，这样的框架从技术上来说似乎并没有太多困难。

以上就对ASP.NET Routing中的“解析URL”功能进行了介绍。本文来自老赵点滴：《复用类库内部已有功能》

分享文章：ASP.NETRouting之“解析URL”功能详解
链接地址：http://www.shufengxianlan.com/qtweb/news9/225309.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联