NET/ASP NET路由(深入分析路由系统架构原理)

1]开头介绍

这篇文章让我们很高兴学习ASP.NET的核心对象模型Routing模块。为什么说是幸福？因为Routing是基于熟悉的ASP.NET管道模型，会比其他不熟悉的概念容易很多，但是再生一次再成熟也没关系；

ASP。NET路由系统是所有通过ASP.NET访问URIs的应用程序的基础(不是物理文件的直接映射)；随着路由的出现，我们的网页设计已经和以前大不相同了。越来越轻量和简化，都是由简单的Uri资源来处理，并且专注于业务设计；目前主流的Rest ful api也是在这样的机制下建立的，但是我们的ASP。NETMVC也是通过独立的URIs进行程序访问处理的框架，所以也是在ASP.NET路由建立的；然后是流行的ASP.NET技术(ASP。NET网络应用编程接口)。它们都建立在Routing框架上，这说明它相当重要；

因此，本文让我们来分析Routing的工作原理，以及为什么它能在不影响现有框架的情况下提供如此好的可扩展性，这确实让人想搞清楚；目前我们都知道ASP.NET现有的框架知识，大概也知道它一定在哪里截取了ASP.NET管道模型；

让我们利用这条重要的线索，一点一点地找出它是如何支持其他框架的。我最困惑的是它是如何区分网页和MVC的。最重要的是它如何只提供一个接口，以便后续的相关框架可以基于这个通用的Routing接口进行扩展。它的对象模型一定很聪明。我们需要理解它，以便有信心继续对我们的ASP.NET相关框架进行后续研究；

注意：全文使用路由一词代替ASP。网络路由，以免概念混淆。

2]位置2]ASP。网络路由对象模型

问Asked最重要的扩张点在哪里？我想大家都会异口同声地说：关于管道模型，这也符合解决这个问题的一个基本思路；每个人都知道ASP.NET管道模型。只要定义了管道模型中的相关事件，就可以将自己的逻辑插入到管道处理中；流水线的最终执行接口为IHttpHander类型，只需防止创建原来默认的IHttpHander接口，就有可能改变整个处理流程；

图2.1:

那么路由只有在阻止创建IHttpHander接口之前执行，才能反转整个处理路由的机会。上图所示的应用事件(2) (IHttpHander执行)意味着其他定制的IHttpHander只能在IHttpHander执行之前的一个应用事件中执行；而IHttpHander是ASP.NET框架的最终执行接口，所以要想改变最初执行Page的Hander，需要提供一个自定义的IHttpHander接口对象；

换句话说，所有的执行条目实际上都在IHttpHander中。ProcessRequest()方法，但现在的矛盾是ASP.NET路由卡在中间，这让原来的直接处理流程有点混乱，而且它把“ASP。NET基本框架“从”ASP。基于. NET的应用程序框架”(如ASP。NETMVC\ASP。NETWEBAPI\自定义框架)；

注：“ASP。NET基本框架”指的是ASP。NET自己的框架，可以理解为传统的WEBFROM；“基于ASP的应用框架。NET”是指基于ASP.NET基础框架设计的上层轻量级应用框架，如MVC \网页\ WEBAPI

图2.2:

事实上，这张图清楚地显示了ASP的位置。网络路由，这是ASP.NET和ASP之间的关键链接。根据我们上面的分析思路，路由是ASP.NET框架直接交互的对象模型，所以来自ASP。NET的观点，它不知道背后发生了什么。其实ASP。在ASP的某个生活事件中，网络路由取代了原有的创建逻辑。NETApplication

3.】3的入口。】ASP。网络路由路由对象模型

路由扮演中间人的角色，透明地封装了ASP.NET的相关逻辑。虽然我们可以在路由的上层使用相关的ASP.NET对象，但概念已经发生了根本性的变化；我们可以随意引入一个自定义的IHttpHander实现类，并根据前端发送的Uri执行策略，也就是说你