《第2章 路由》.pdfVIP

第2 章 路由 对于传统的ASP.NET Web Forms 应用来说，用户请求总是指向某个具体的 物理文件，目标文件的路径决定了访问请求的URL。但是对于ASP.NET MVC 应用来说 ，来自浏览器的请求总是指向定义在某个 Controller 类型中的某个 Action 方法 ，请求URL 与目标Controller/Action 之间的映射是通过“路由”来实现 的。 ASP.NET MVC 5 框架揭秘 52 第2 章 路由 2.1 ASP.NET 路由 由于来自客户端的请求总是指向定义在某个Controller 类型中的某个Action 方法，并且目 标Controller 和Action 的名称由请求URL 决定，所以必须采用某种机制根据请求URL 解析出 目标Controller 和Action 的名称，我们将这种机制称为“路由 （Routing ）”。但是路由系统并不 是专属于ASP.NET MVC 的，而是直接建立在ASP.NET 上 （实现路由的核心类型基本上定义 在程序集 “System.Web.dll”中）。路由机制同样可以应用在Web Forms 应用中，它可以帮助我 们实现请求地址与物理文件的分离。 2.1.1 请求URL 与物理文件的分离 对于一个 ASP.NET Web Forms 应用来说，通常情况下一个有效的请求都对应着一个具体 的物理文件。部署在Web 服务器上的物理文件可以是静态的（比如图片和静态HTML 文件等）， 也可以是动态的（比如.aspx 页面）。对于静态文件的请求，ASP.NET 会直接返回文件的原始内 容，而针对动态文件的请求则会涉及相关代码的执行。这种将 URL 与物理文件紧密绑定在一 起的方式并不是一种好的解决方案，它带来的局限性主要体现在如下几个方面。  灵活性。物理文件的路径决定了访问它的 URL，如果物理文件的路径发生了改变（比如改 变了文件的目录结构或者文件名），原来访问该文件的URL 将变得无效。  可读性。在很多情况下，URL 不仅仅具备基本的可用性（能够访问正确的网络资源），还 需要具有很好的可读性。好的URL 设计应该让我们一眼就能看出针对它访问的目标资源 是什么，请求地址与物理文件紧密绑定让我们完全失去了设计高可读性URL 的机会。  SEO 优化。对于网站开发来说，为了迎合搜索引擎检索的规则，我们需要对URL 进行有效 的设计，使之能易于被主流的引擎检索收录。如果URL 完全与物理地址关联在一起，这无 异于失去了SEO 优化的能力。 上述3 个因素促使我们不得不采用一种更加灵活的映射机制来实现请求URL 与目标文件 路径的分离。那么有什么办法能够帮助实现两者之间的分离呢？可能很多人会想到一个叫作 “URL 重写”的机制。为了使Web 应用可以独立地设计用于访问应用资源的URL，微软为IIS 7 编写了一个URL 重写模块。这是一个基于规则的URL 重写引擎，它在URL 被Web 服务器 处理之前根据定义的规则重定向某个物理文件。 ASP.NET MVC 5 框架揭秘 53 URL 重写机制在IIS 级别解决了URL 与物理地址的分离，它的实现依赖于一个注册到IIS 管道上的本地（Native ）代码模块，所以它可以应用于寄宿在IIS 中的所有Web 应用类型。与 URL 重写机制不同，路由系统则是ASP.NET 的一部分，并且是通过托管代码编写的。为了让 读者对ASP.NET 的路由系统具有一个感官的认识，我们来演示一个简单的实例。 2.1.2 实例演示：通过路由实现请求地址与.aspx 页面的映射 （S201 ） 我们创建一个简单的ASP.NET Web Forms 应用，并采用一套独立于.aspx 文件路径的URL