使用ASP.NET Web窗体路由

使用ASP.NET Web窗体路由2011-12-06 msdn Scott AllenMicrosoft .NET Framework 3.5 Service Pack 1 在 ASP.NET 运行时中引入了路由引擎。路由引擎可以从响应传入 HTTP 请求的实际 Web 窗体中分离该请求中的 URL，使您能够为 Web 应用程序构建友好的 URL。尽管在以前版本的 ASP.NET 中也一直都能够使用友好的 URL，但路由引擎却提供了一种更简单、更明晰和更容易测试的方法。

路由引擎最初是 ASP.NET 模型视图控制器（MVC）框架的一部分，在撰写本文时它仍处于预演阶段。但是，Microsoft 将路由逻辑封装到了 System.Web.Routing 程序集中，并随同 SP1 发布了该程序集。目前该程序集使用 ASP.NET 动态数据功能（它们也随 SP1 一起发布）为网站提供路由，但在本专栏中，我将介绍如何通过 ASP.NET Web 窗体来使用路由功能。

什么是路由？

假设您有一个名为 RecipeDisplay.aspx 的 ASP.NET Web 窗体，此窗体位于一个名为 Web Forms 的文件夹中。使用此 Web 窗体查看方案时，传统方法是构建一个指向该窗体实际位置的 URL，并将某些数据通过编码方式嵌入到查询字符串中，以告知 Web 窗体要显示的方案。此类 URL 的结尾可能如下所示：/WebForms/RecipeDisplay.aspx？id=5，其中数字 5 代表在一个充满方案的数据库表中的主键值。

路由从本质上来说就是把一个 URL 端点分解成多个参数，然后使用这些参数将 HTTP 请求处理引导至特定的组件。让我们以 URL /recipe/5 为例。借助正确的路由配置，您仍可以使用 Web 窗体 RecipeDisplay.aspx 来响应此 URL。

此时 URL 不再代表实际的路径。单词 recipe 变为代表一个参数，路由引擎可以用它找到处理 recipe 请求的组件。数字 5 代表第二个参数，在处理期间用它显示某个特定的 recipe。此时不宜通过编码将数据库关键字嵌入 URL 中，更好的做法是使用形如 /recipe/tacos 的 URL。此 URL 不但包括足够多的参数来显示特定的 recipe，还非常便于人们阅读理解，它可以为最终用户揭示其意图，并包括一些重要的关键字供搜索引擎使用。

URL 重写的简史

在 ASP.NET 中，使用以 /recipe/tacos 结尾的 URL 时，从传统上而言需要有人来处理 URL 重写架构。有关 URL 重写的详细信息，请参阅 Scott Mitchell 撰写的权威文章“在 ASP.NET 中执行 URL 重写”。该文描述了在 ASP.NET 中使用 HTTP 模块和 HttpContext 类的静态 RewritePath 方法重写 URL 的常见途径。Scott 的文章还详细说明了友好且可改动 URL 的优点。

在过去曾使用过 RewritePath API 的用户可能非常清楚重写方法中的某些怪异现象和缺点。RewritePath 面临的主要问题是在处理请求的过程中该方法如何更改所使用的虚拟路径。使用 URL 重写时，需要设定每个 Web 窗体的回发目标（通常通过在请求过程中再次重写 URL 来实现），以避免回发转到内部已重写的 URL。

此外，大多数开发人员在实现 URL 重写时都采用单向转换模式，因为无法通过任何简单的机制使 URL 重写逻辑双向工作。例如，要赋予 URL 重写逻辑一个面向公众的 URL 并使该逻辑返回 Web 窗体的内部 URL 非常容易。但是，要为 Web 窗体的内部 URL 赋予重写逻辑并使其返回进入窗体所需的公共 URL 却很困难。生成到隐藏在被重写的 URL 中的其他 Web 窗体的超链接时，后者会非常有用。本专栏的其余部分介绍了 URL 路由引擎如何解决这些问题。

图 1 路由、路由处理程序和路由模块