让我们从一个典型的ASP.NET Web请求的生命周期的起点开始。当用户输入一个URL，点击了一个超链接或者提交了一个HTML表单(form)(一个POST请求，相对于前两者在一般意义上都是GET请求)。或者一个客户端程序可能调用了一个基于ASP.NET的WebService(同样由ASP.NET来处理)。在Web服务器端，IIS5或6，获得这个请求。在最底层，ASP.NET和IIS通过ISAPI扩展进行交互。在ASP.NET环境中这个请求通常被路由到一个扩展名为.aspx的页面上，但是这个流程是怎么工作的完全依赖于处理特定扩展名的HTTP Handler是怎么实现的。在IIS中。aspx通过’应用程序扩展’(又称为脚本映射)被映射到ASP.NET的ISAPI扩展DLL-aspnet_isapi.dll。每一个请求都需要通过一个被注册到aspnet_isapi.dll的扩展名来触发ASP.NET(来处理这个请求)。

　　依赖于扩展名ASP.NET将请求路由到一个合适的处理器(handler)上，这个处理器负责获取这个请求。例如，WebService的。asmx扩展名不会将请求路由到磁盘上的一个页面，而是一个由特殊属性(Attribute)标记为WebService的类上。许多其他处理器和ASP.NET安装，当然你也可以自定义处理器。所有这些HttpHandler在IIS中被配置为指向ASP.NET ISAPI扩展，并在web。config(译著:ASP.NET中自带的handler是在machine。config中配置的，当然可以在web.config中覆盖配置)被配置来将请求路由到指定的HTTP Handler上。每个handler都是一个处理特殊扩展的。NET类，可以从一个简单的只包含几行代码的Hello World类，到非常复杂的handler如ASP.NET的页面或者WebService的handler。当前，只要了解ASP.NET的映射机制是使用扩展名来从ISAPI接收请求并将其路由到处理这个请求的handler上就可以了。

　　对在IIS中自定义Web请求处理来说，ISAPI是第一个也是最高效的入口。

　　ISAPI连接

　　ISAPI是底层的非托管Win32 API。ISAPI定义的接口非常简单并且是为性能做了优化的。它们是非常底层的-处理指针和函数指针表来进行回调-但是它们提供了最底层和面向效率的接口，使开发者和工具提供商可以用它来挂接到IIS上。因为ISAPI非常底层所以它并不适合来开发应用级的代码，而且ISAPI倾向于主要被用于桥接接口，向上层工具提供应用服务器类型的功能。例如，ASP和ASP.NET都是建立在ISAPI上的，Cold Fusion，运行在IIS上的多数Perl，PHP以及JSP实现，很多第三方解决方案(如我的Wisual FoxPro的Web连接框架)都是如此。ISAPI是一个杰出的工具，可以为上层应用提供高效的管道接口，这样上层应用可以抽象出ISAPI提供的信息。在ASP和ASP.NET中，将ISAPI接口提供的信息抽象成了类型Request和Response这样的对象，通过它们来读取ISAPI请求中对应的信息。将ISAPI想像成管道。对ASP.NET来说，ISAPI dll是非常的”瘦”的，只是作为一个路由机制来将原始的请求转发到ASP.NET运行时。所有那些沉重的负担和处理，甚至请求线程的管理都发生在ASP.NET引擎内部和你的代码中。

　　作为最为协议，ISAPI同时支持ISAPI扩展和ISAPI过滤器(Filter)。扩展是一个请求处理接口，提供了处理Web服务器的输入输出的逻辑-它本质上是一个处理(事物?)接口。ASP和ASP.NET都被实现为ISAPI扩展。ISAPI过滤器是挂接接口，提供了查看进入IIS的每一

[1] [2] 下一页

在google里搜索更多ASP.NET底层架构之从浏览器到ASP.NET

	Web www.51ec.org

上一篇信息学院： ASP.NET技巧：COOKIE问题

下一篇信息学院： .NET下的设计模式研究之桥接模式