我们列举了各种URL生成的方式，其中大致可以分为三类：

1. 直接拼接字符串（方法一及方法二）
2. 使用Route规则生成URL（方法三）
3. 使用Lambda表达式生成URL（方法四及方法五）

我们可以轻易得知，这3种作法可维护性依次增加，而性能依次减少。不过，我们还是有一个疑问，这个性能究竟相差多少？它是否的确真的可以被忽略？为此，我们还是来进行一次性能对比吧。

测试对象

为了获得贴近实际的测试结果，我打算以我的博客首页作为测试对象。您可以发现，这个页面上的链接非常多，我把它分为三个部分：

1. 文章（Post）列表：主体部分的40篇文章，其中每篇文章包含1个详细页链接以及5个Tag。
2. 边栏文章列表：假设边栏列举了120篇文章的链接。
3. 归档（Archive）列表：也就是每个月的文章链接，3年共36个链接。

作为一个演示，我也精心准备了四种URL模式，它们分别是：

// 博客首页
routes.MapRoute(
    "Blog.Index",
    "{blog}",
    new { controller = "Blog", action = "Index" });

// 标签页
routes.MapRoute(
    "Blog.Tag",
    "{blog}/tag/{tag}",
    new { controller = "Blog", action = "Tag" });

// 按月归档页
routes.MapRoute(
    "Blog.Archive",
    "{blog}/archive/{year}/{month}.html",
    new { controller = "Blog", action = "Archive" });

// 文章详细页
routes.MapRoute(
    "Blog.Post",
    "{blog}/archive/{*post}",
    new { controller = "Blog", action = "Post" });

以上代码在Web项目中的GlobalApplication.cs文件中。您可以发现，我完全按照博客园在定制URL的模式。我想说明的是，其实URL Routing完全非常灵活，您可以根据需求使用各种形式的URL，关键只是“规则配置”而已。不过虽然配置了4种Route规则，但是我只实现了BlogController下的一个Action：博客首页（Index），如下：

[RouteName("Blog.Index")]
public ActionResult Index(
    [ModelBinder(typeof(BlogBinder))]Blog blog, string view)
{
    var model = new IndexModel { Blog = blog, Posts = GetPosts() };
    return View("Index" + view, model);
}

private static List<Post> GetPosts()
{
    ...
}

[RouteName("Blog.Post")]
public ActionResult Post(
    [ModelBinder(typeof(BlogBinder))]Blog blog,
    [ModelBinder(typeof(PostBinder))]Post post)
{
    throw new NotImplementedException();
}

[RouteName("Blog.Tag")]
public ActionResult Tag(
    [ModelBinder(typeof(BlogBinder))]Blog blog,
    [ModelBinder(typeof(StringBinder))]string tag)
{
    throw new NotImplementedException();
}

[RouteName("Blog.Archive")]
public ActionResult Archive(
    [ModelBinder(typeof(BlogBinder))]Blog blog,
    int year,
    int month)
{
    throw new NotImplementedException();
}

BlogController.cs文件处于Web.Controllers项目中。我为每个复杂参数都安排了ModelBinder，具体实现都很简单，您可以下载文末的代码进行浏览。在GetPosts里我将准备40个Post对象，每个Post对象分配5个Tag，这些都将显示在页面上。Index方法的参数view通过Query String进行传递，例如，您可以通过一下三个链接来访问不同的URL生成方式：

• /jeffz?view=ByRaw：使用拼接字符串的方式生成URL
• /jeffz?view=ByRoute：使用Route规则生成URL
• /jeffz：使用Lambda表达式这个“推荐方式”生成URL

三种方式

在Web.UI项目中的Views目录下有BlogController所使用的三个视图模板，他们使用不同的方式来生成完全一样的内容。例如Index.aspx文件中的定义是这样的：

<!-- 主体文章列表，40篇，各5个Tag -->
<h2>Posts</h2>
<ul>
    <% foreach (var post in Model.Posts) { %>
        <li>
            Title: <a href="<%= Url.ToPost(Model.Blog, post) %>"><%= Html.Encode(post.Title) %></a>
            Tag: 
            <% foreach (var tag in post.Tags) { %>
                <a href="<%= Url.ToTag(Model.Blog, tag) %>"><%= Html.Encode(tag) %></a> | 
            <% } %>
        </li>
    <% } %>
</ul>

<!-- 边栏文章列表，共计120篇 -->
<h2>More post links</h2>
<ul>
    <% for (int i = 0; i < 3; i++) { %>
        <% foreach (var post in Model.Posts) { %>
            <li style="display: inline;">
                <a href="<%= Url.ToPost(Model.Blog, post) %>"><%= Html.Encode(post.Title) %></a> |
            </li>
        <% } %>
    <% } %>
</ul>

<!-- 归档列表，3年共计36个链接 -->
<h2>Archives</h2>
<ul>
    <% for (int year = 2007; year <= 2009; year++) { %>
        <% for (int month = 1; month <= 12; month++) { %>
            <li>
                <a href="<%= Url.ToArchive(Model.Blog, year, month) %>"><%= year %>年<%= month %>月</a>
            </li>
        <% } %>
    <% } %>
</ul>

对于IndexByRaw.aspx和IndexByRoute.aspx来说，它们只是把ToPost，ToTag等方法改为对应的ToPostByRaw或ToTagByRoute而已。因此，其实生成URL的关键还在于这些辅助方法。例如ToPost，ToTag和ToArchive三个扩展方法是这样实现的：

public static string ToPost(this UrlHelper helper, Blog blog, Post post)
{
    return helper.Action<BlogController>(c => c.Post(blog, post));
}

public static string ToTag(this UrlHelper helper, Blog blog, string tag)
{
    return helper.Action<BlogController>(c => c.Tag(blog, tag));
}

public static string ToArchive(this UrlHelper helper, Blog blog, int year, int month)
{
    return helper.Action<BlogController>(c => c.Archive(blog, year, month));
}

可见，使用Lambda表达式构造URL的代码非常清晰，简单，直观——因为Action辅助方法会自动从Lambda表达式中提取Controller和Action名，并调用每个参数的RouteBinder实现复杂类型参数的双向转化，它不需要我们关心更多的东西。

而如果直接拼接字符串，那么它可能就是这样的：

public static string ToTagByRaw(this UrlHelper helper, Blog blog, string tag)
{
    return blog.Alias + "/tag/" + HttpUtility.UrlEncode(tag);
}

而基于Route构造URL就会显得略麻烦一些：

public static string ToTagByRoute(this UrlHelper helper, Blog blog, string tag)
{
    var path = helper.RouteCollection.GetVirtualPathEx(
        helper.RequestContext,
        "Blog.Tag",
        new RouteValueDictionary
        {
            { "controller", "Blog" },
            { "action", "Tag" },
            { "blog", blog.Alias },
            { "tag", HttpUtility.UrlEncode(tag) }
        });

    return path.VirtualPath;
}

至于后两种方式的其它几个辅助方法，您可以下载文末的代码进行浏览，它们都在Web.Controllers项目中的UrlGenExtensions.cs文件中。

运行测试

我们使用BlogController中另一个Action方法：Benchmark进行性能测试。Benchmark方法接受两个参数，一个是循环次数，而另一个则是测试目标：

public ActionResult Benchmark(int iteration, string view)
{
    var model = new IndexModel
    {
        Blog = new Blog { Alias = "jeffz" },
        Posts = GetPosts()
    };

    var result = new BenchmarkModel
    {
        Iteration = iteration,
        View = "Index" + view
    };

    var viewInstance = new WebFormView("~/Views/Blog/Index" + view + ".aspx");

    var viewContext = new ViewContext(
        this.ControllerContext,
        viewInstance,
        new ViewDataDictionary(model),
        new TempDataDictionary());

    // warm up
    viewInstance.Render(viewContext, new StringWriter());

    GC.Collect();

    var watch = new Stopwatch();
    watch.Start();

    for (int i = 1; i <= iteration; i++)
    {
        viewInstance.Render(viewContext, new StringWriter());

        if (i % 100 == 0)
        {
            result.Add(i, watch.Elapsed);
        }
    }

    watch.Stop();

    return View(result);
}

于是，您可以使用下面的链接观察使用三种方法生成1000次页面所消耗的时间：

• /benchmark?iteration=1000&view=ByRaw：使用拼接字符串的方式生成URL
• /benchmark?iteration=1000&view=ByRoute：使用Route生成URL
• /benchmark?iteration=1000：使用Lambda表达式生成URL

Benchmark方法会每隔100次记录一下结果，因此上面的链接加载完后会出现10条信息——这便是我们得到的结果。

结果

至于最终的结果以及分析，我打算暂时卖个关子，不多久我就会独立开篇进行说明的。您可以在这里下载到整个解决方案，代码不多，但也花费了我2个小时进行准备，您可以亲自试验一下。您直接使用上面的Benchmark链接进行观察即可，生成1000次页面已经足以展示一些问题了——不过在此之前，您不妨进行一个预测，猜猜看它们之间究竟有多大的性能差距。