代码改变世界

支持DomainRoute的URL构造辅助方法

2009-08-26 12:18 Jeffrey Zhao 阅读(...) 评论(...) 编辑 收藏

上一篇文章中我们构造了DomainRoute类,这是一个将URL Routing扩展至域名的Route组件,于是现在我们便可以轻易地从一个URL的Domain部分中捕获数据并在程序中使用。不过作为URL Routing的另一个重要部分,在URL构建方面,我们还需给DomainRoute补充额外的支持。

我想再次强调一下,URL Routing的功能并不只是从URL中捕获数据,它还有一个作用便是根据数据组装出一个URL。简单地说,URL Routing的功能是“双向”的。这也是为什么默认的Route组件会使用{controller}/{action}这样的简单模式,而不是常用的成熟的正则表达式,这就是因为正则表达式能够根据模式来匹配出值来,但是无法根据“值”反过来构建一个字符串。

在编写ASP.NET MVC的视图时,我们需要在HTML中填充链接的URL。在最初的时刻,我们会直接放上“约定”好的字符串,但是更好的方式显然是使用辅助方法。记得在搞URL Rewrite时,常常有朋友问我“页面中填写的URL怎么变成‘漂亮’的样子”,对此我只能说“没办法,直接写吧”,接着自然是一阵大改。而通过辅助方法来构造URL,由于我们只要向URL Routing提供数据,而Route会自动根据配置构造出一个可供自己识别的URL。如果我们想改变URL样式,只要在一个地方改变URL Routing的配置即可,页面中所有的URL便会同时改变了。

我认为,这也是遵守DRY原则的经典示例之一。

在ASP.NET MVC中已经自带了一部分构造URL所使用的辅助方法,例如在UrlHelper类中已经包含了Action方法(以及许多重载)。但是这些个方法并不适合FormatRoute。因为在这些实现最终都使用了RouteCollection的GetVirtualPath方法,它会把Route所得到的URL作为“虚拟路径”对待,这意味着FormatRoute返回了http://www.cnblogs.com/JeffreyZhao/这样的URL之后,也会当作是一个普通的Path,最终在页面上便会出现“/http:/www.cnblogs.com/JeffreyZhao/”这样的URL,这显然是错误的。

这样看来,难道ASP.NET Routing本身是“不打算”支持域名的吗?似乎我们又不仅仅是在“扩展”,又出现“Hack”的意味了。

不过知道了错误原因之后,修改起来就非常容易了。例如,我们可以为UrlHelper补充一个扩展方法叫做ActionEx,实现起来也就几行代码:

public static string ActionEx(this UrlHelper helper, string action, object routeValues)
{
    var values = routeValues == null ?
        new RouteValueDictionary() : 
        new RouteValueDictionary(routeValues);
    values.Add("action", action);
    values.Add("controller", helper.RequestContext.RouteData.Values["controller"]);

    var pathData = helper.RouteCollection.GetPath(helper.RequestContext, values);
    var url = pathData.VirtualPath;
    return IsAbsolute(url) ? url : "/" + url;
}

private static VirtualPathData GetPath(
    this RouteCollection routes,
    RequestContext requestContext,
    RouteValueDictionary values)
{
    foreach (RouteBase r in routes)
    {
        VirtualPathData pathData = r.GetVirtualPath(requestContext, values);
        if (pathData != null)
        {
            return pathData;
        }
    }

    throw new ArgumentException("Invalid values for building URL.");
}

private static bool IsAbsolute(string url)
{
    return
        url.StartsWith("http://", StringComparison.InvariantCultureIgnoreCase) ||
        url.StartsWith("https://", StringComparison.InvariantCultureIgnoreCase);
}

要做的事情还是分三步走:

  1. 收集route values
  2. 从route配置中获得URL
  3. 处理URL并返回

根据FormatRoute的逻辑,返回的URL可能有两种情况:

  • 如果目标地址与当前请求的域名相同,则地址为一个相对路径,如“Home/Index/5”。
  • 如果目标地址与当前请求的域名不同,则地址为一个绝对路径,如“http://space.cnblogs.com/Home/Index/5”。

两种地址的处理方式自然不同,而我们目前的处理方式是最简单的:在相对路径之前加一个斜杠“/”。很明显,这里做了一个“假设”,那就是我们的ASP.NET MVC应用程序是部署在域名的根目录下的(似乎DomainRoute本身也有这样的要求)。如果您的应用程序部署在一个虚拟目录下,这部分逻辑自然是需要修改的。不过作为大部分应用来说,现在的功能应该已经足够使用了。

试验一番吧。例如我们使用这样的Route配置:

var defaults = new RouteValueDictionary(new { controller = "Home", action = "Index", id = "" });
var route =
    new Route("{controller}/{action}/{id}", defaults, new MvcRouteHandler())
    .WithDomain("http://{area}.{*domain}");
routes.Add("Default", route);

然后请求http://www.jeffz-test.com/Home/Index,并在相应视图中写下这样的代码:

<a href="<%= Url.ActionEx("List", null) %>">List</a>
<a href="<%= Url.ActionEx("LogIn", new { id = 10, area = "account" })%>">Accout LogIn</a>

于是在页面上就会生成这样的HTML:

<a href="/Home/List">List</a> 
<a href="http://account.jeffz-test.com/Home/LogIn/10">Accout LogIn</a>

看上去不错吧?

ASP.NET MVC中的其他与构造URL功能有关的辅助方法,如ActionLink,其实也都是相同的原理。如果您需要的话,也不妨自己实现一个对应的ActionLinkEx方法。

不过,根据尽可能强类型的原则,我们应该使用的是MvcFutures中定义的基于表达式树的辅助方法。不过MvcFutures里的这些方法有些问题,如最常见的“视ActionNameAttribute于无物”。在使用过程中我也遇到了其他一些问题,下次我们再来改造这些辅助方法。

在条件充分的时候,使用表达式树来表示URL构造,可以说有百利而无一害。