控制器 - URL routing HTTP module（一）

URL routing HTTP module 负责处理检查入站请求的 URL，并将它们分派到最合理的处理器上。URL routing HTTP module 也替代了旧版本的 ASP.NET URL 重写特性。核心方面，URL 重写由 连接请求，转换原始 URL，指导 HTTP 运行时环境处理一个“最可能相关但存在区别”的 URL 这几个部分组成。

替代 URL 重写

如果我们需要在路由可读性、面向搜索引擎友好和需要以编程的方式处理若干的 URLs 方面上做权衡，那么，URL 重写就发挥作用了。比如，我们考虑以下 URL:

http://northwind.com/news.aspx?id=1234

news.aspx 页面包含了一些逻辑需要检索，格式化，并且显示相应新闻。特定新闻编号的检索通过查询字符串中的参数提供。作为一名开发者，实现这样的页面并非很容易，首先获得查询字符串的参数，然后执行查询，最后创建 HTML 页面，可是你也并非非常容易地记住这些 URL 地址。

然而 URL 重写可以在两个方面帮助你。第一，它让开发者使用通用的面向前端的页面成为可能，比如 news.aspx，来展示相关的内容。第二，它让用户访问更加友好的 URL 成为可能，这些 URL 都是通过编程的方式映射到敏感度降低但是更加易于管理的 URL 上。简单来说，URL 重写的存在就是为了降低请求的 URL 与处理请求的物理页面的耦合度。

在上个版本的 ASP.NET 4 Web Forms 中，你可以通过 URL 重写来匹配入站 URL 到其他的 URL 上，而非使用 HTTP 302 重定向的代价。相反的，在 ASP.NET MVC 里，URL 路由的目标就是将入站 URL 映射到对应的控制器和对应的行为方法上。

注意： URL routing module 原本开发为 ASP.NET MVC 的一个组件，但现在是 ASP.NET 平台一个原生的部分，正如上面所提，它同时向 ASP.NET MVC 和 ASP.NET Web Forms 应用提供服务，虽然通过一个稍微有点差别的 API.

路由请求

当一个请求到达 IIS 究竟发生了什么？

URL routing module 为应用拦截任何无法被 IIS 处理的请求。如果这个 URL 指向一个物理文件（比如，一个 ASPX 文件），routing module 就会忽略这个请求，除非这个 URL 被特别配置过。然后这个请求就会落到传统的 ASP.NET 机制上并被处理，也就是 page handler。

相反的，URL routing module 会尝试将请求 URL 与应用定义好的路由经行匹配。如果匹配成功，这个请求就会进入 ASP.NET MVC 空间并被处理。如果没有匹配成功，这个请求就会被标准的 ASP.NET 运行时所处理，并且很可能导致 HTTP 404 错误的显示。

最后，仅有那些匹配预先定义的 URL 模式的请求可以进入 ASP.NET MVC 运行时。所有的这些请求将会被路由到一个公共的 HTTP handler 上，它可以实例化一个控制器类并调用它当中的定义好的方法。然后，这个控制器中的方法，反过来会选择一个视图组件，并生成响应。

URL routing module 内部结构

依据实现原理，URL routing 引擎是一个封装了 PostResolveRequestCache 事件的 HTTP 模块。这个事件会在如果 ASP.NET 缓存中没有对应请求的响应时立即被启动。

HTTP module 将请求的 URL 与一个用户自定义的 URL 路由匹配，设置 HTTP context，并使用 ASP.NET MVC 标准 HTTP handler 处理请求。作为一个开发者，我们并不太可能直接与 URL routing module 打交道。这个模块由系统直接提供，并且你也不需要做相应形式的配置。然后，你有义务为你的应用提供相应的路由，而这个将会被 routing module 使用到。

【声明：本文是个人翻译而来。当中可能会存在许多不当之处，万望指出，谢谢。文章会持续更新】