浅谈URL生成方式的演变
2009-10-29 00:29 by 老赵, 19724 visits开发Web应用程序的时候，在页面上总会放置大量的链接，而链接的生成方式看似简单，也有许多不同的变化，且各有利弊。现在我们就来看看，在一个ASP.NET MVC应用程序的视图中如果要生成一个链接地址又有哪些做法，它们之间又是如何演变的。
目标
作为示例，我们总要有个目标URL。我们这里的目标为面向如下Action的URL，也就是一篇文章的详细页：
public class ArticleController : Controller { public ActionResult Detail(Article article) { ... } } public class Article { public int ArticleID { get; set; } public string Title { get; set; } }
而我们的目标URL则是文章的ID与标题的联合，其中标题里的空格替换为很短横线——把文章的标题放入URL自然是为了SEO。于是乎我们使用这样的Route规则：
routes.MapRoute(
"Article.Detail", // Route name
"article/{article}", // URL with parameters
new { controller = "Article", action = "Detail" } // Parameter defaults
);
在URL Routing捕获到article之后，它的形式可能是这样的：
10-this-is-the-title
我们只考虑这个ID，后面的字符串虽然在URL中，但是完全被忽略。在实际项目中，我们可以编写一个Model Binder从这样一个字符串中提取ID，再获取对应的Article对象。不过我们的现在不关注这个。
我们的目标只有一个：如何生成URL。
方法一：直接拼接字符串
这是个最直接，最容易想到的做法：
<% foreach (var article in Models.Articles) { %> <a href="/article/<%= article.ArticleID %>-<%= Url.Encode(article.Title.Replace(' ', '-')) %>"> <%= Html.Encode(article.Title) %> </a> <% } %>
这个做法随着ASP.NET的诞生陪伴我们一路走来，已经有7、8个年头了，相信大部分朋友对它都不会陌生。它的优点自然是最为简单，最为直接，几乎没有任何门槛，也不需要任何准备就可以直接使用，而且理论上性能也是最佳的。但是它的缺点也很明显，那就是需要在每个页面，每个地方都重复这样一个字符串。试想，如果我们URL的生成规则忽然有所变化，又会怎么样？我们必须找出所有的生成链接的地方，一个一个改过来。这往往是一个浩大的工程，而且非常容易出错——因为我们根本没有静态检查可以依托。因此，在实际情况下，除非是快速开发的超小型的，随做随抛的实验性项目，一般不建议使用这样的做法。
方法二：使用辅助方法
为了避免方法一的缺点，我们可以使用一个辅助方法来生成URL：
public static class ArticleUrlExtensions { public static string ToArticle(this UrlHelper helper, Article article) { return "/article/" + article.ArticleID + "-" + helper.Encode(article.Title.Replace(' ', '-')); } }
我们把负责生成URL的辅助方法写作UrlHelper的扩展方法，于是我们就可以在页面上这样生成URL了（省略多余标记）：
<a href="<%= Url.ToArticle(article) %>">...</a>
这个做法的优点在于把生成URL的逻辑汇集到了一处，这样如果需要变化的时候只需要修改这一个地方就行了，而且它几乎没有任何副作用，使用起来也非常简单。而它的缺点还是在于有些重复：如果这个URL修改涉及到Route配置的变化（例如从http://www.domain.com/article/5变成了http://articles.domain.com/5），则ToArticle方法也必须随之修改。也就是说，这个方法对DRY（Don’t Repeat Yourself）原则贯彻地还不够彻底。不过，对于一般项目来说，这个做法也不会有太大问题——这也是构造URL方式的底线。
方法三：从Route配置中生成URL
对于URL Routing的双向职责我已经提过无数次了，我们配置了Route规则，那么便可以使用它来生成URL：
public static string ToDetail(this UrlHelper helper, Article article) { var values = new { article = article.ArticleID + "-" + helper.Encode(article.Title.Replace(' ', '-')) }; var path = helper.RouteCollection.GetVirtualPath( helper.RequestContext, "Article.Detail", new RouteValueDictionary(values)); return path.VirtualPath; }
由于Route配置知道如何根据Route Value集合里的值生成一个URL，因此我们只要把这个职责交给它即可。一般来说，我们会指定Route规则的名称，这样节省了遍历尝试每个规则的开销，也不会被冲突问题所困扰。此时，即便是URL需要变化，只要调整Route规则即可——只要保持规则对“值”的需求不变就行了。例如之前提到的URL的变化，我们只要把Route配置调整为：
routes.MapDomain(
"Article",
"http://articles.{*domain}",
innerRoutes =>
{
innerRoutes.MapRoute(
"Detail",
"",
new { controller = "Article", action = "Detail" });
};
这个做法的优点在于“自动”与Route配置同步，几乎不需要额外的逻辑。而它的缺点——可能在从性能角度上考虑会有“细微”的差距（在实际应用中是否重要另当别论）……
方法四：使用Lambda表达式生成URL
我也经常强调使用Lambda表达式生成URL的好处：
<a href="<%= Url.Action<ArticleController>(c => c.Detail(article)) %>">...</a>
由于在ASP.NET MVC中，一个URL的最终目标归根到底是一个Action，因此如果我们可以更直观地在代码中表现出这一点，则可以进一步提高代码的可读性。这一点在ASP.NET MVC 1.0自带的MvcFutures项目中已经有所体现，只可惜它作的远远不够，几乎没有任何实用价值。不过现在您也可以使用MvcPatch项目进行开发，它提供了完整的使用Lambda表达式生成URL的能力，它相对于MvcFutures里的辅助方法作了各种补充：
使用这种方式，我们需要对Action方法做些简单的修改：
public class ArticleBinder : IModelBinder, IRouteBinder { public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) { ... } public RouteValueDictionary BindRoute(RequestContext requestContext, RouteBindingContext bindingContext) { var article = (Article)bindingContext.Model; var text = article.ArticleID + "-" + HttpUtility.UrlEncode(article.Title.Replace(' ', '-')); return new RouteValueDictionary(new { bindingContext.ModelName = text }); } } public class ArticleController : Controller { [RouteName("Article.Detail")] public ActionResult Detail([ModelBinder(typeof(ArticleBinder))]Article article) { ... } }
请注意我们对Action方法标记了RouteNameAttribute，以此指定Route规则的名称（第4点）；同时，ArticleBinder也实现一个新的接口IRouteBinder负责从Article对象转化为Route Value。
这个做法的优点在于基本上回避了“生成URL”这个工作，而将关注点放在Action方法这个根本的目标上。此外，各种逻辑也很内聚，它们都环绕在Action方法周围，遇到问题也不用四散查询，而将Article对象转化为Route Value的职责也和它的对应操作放在了一起，更容易进行独立的单元测试。此外，使用Lambda表达式生成URL还能获得编译器的静态检查，这确保了可以在编译期间解决尽可能多的问题。
而它的缺点主要是比较复杂，如果您不使用MvcPatch项目的话，可能就需要自行补充许多辅助方法，它们并不那么简单。此外，在视图上的代码页稍显多了一些。还有便是基于表达式树解析的做法多少会有些性能损失，我们下次再来关注这个问题。
方法五：简化Lambda表达式的使用
第五个方法其实是前者的补充。例如，我们可以再准备这样一个辅助方法：
public static class ArticleUrlExtensions { public static string ToArticle(this UrlHelper urlHelper, Expression<Action<ArticleController>> action) { return urlHelper.Action<ArticleController>(action); } }
这样在页面上使用时无须指定ArticleController类了——这类名的确有些长：
<a href="<%= Url.ToArticle(c => c.Detail(article)) %>">...</a>
或者，我们可以结合方法二或三，提供一个额外的辅助方法：
public static class ArticleUrlExtensions { public static string ToArticle(this UrlHelper urlHelper, Article article) { return urlHelper.Action<ArticleController>(c => c.Detail(article)); } }
至于最终使用哪个辅助方法，我想问题都不是很大。前者的“准备工作”更为简单，只需为每个Controller准备一个辅助方法就够了，而后者则需要为每个Action提供一个辅助方法，不过它使用起来却更为方便一些。
这个做法的优点在于继承了Lambda表达式构造URL的优势之外，还简化了它的使用。至于缺点，可能也和Lambda表达式类似吧，例如准备工作较多，性能理论上略差一些。
第五个方法，也是我在ASP.NET MVC项目中使用的“标准做法”。
总结
这次我们把“URL生成”这个简单的目标使用各种方法“演变”了一番，您可以选择地使用。这个演变的过程，其实也是一步步发现缺点，再进行针对性改进的过程。我们虽然使用在ASP.NET MVC的视图作为演示载体，但是它的方式和思路并不仅限于此，它也可以用在ASP.NET MVC的其它方面（如在Controller中生成URL），或是其它模型（如WebForms），甚至与Web开发并无关联的应用程序开发上面。
哦～soga