事情要知道根本所在，原理所在，写程序更应该知道程序的运行机制，本文主要介绍 asp.net的运行内幕
HttpApplication触发事件来通知你的程序有事发生,以此来负责请求流转.这作为HttpApplication.Init()函数的一部分发生(用Reflector查看System.Web.HttpApplication.InitInternal()方法和HttpApplication.ResumeSteps()方法来了解更多详情),连续设置并启动一系列事件,包括执行所有的处理器(handler).这些事件处理器映射到global.asax中自动生成的哪些事件中,同时它们也映射到所有附加的HttpModule(它们本质上是HttpApplication对外发布的额外的事件接收器(sink)).
HttpModule和HttpHandler两者都是根据Web.config中对应的配置被动态载入并附加到事件处理链中.HttpModule实际上是事件处理器,附加到特殊的HttpApplication事件上,然而HttpHandler是用来处理”应用级请求处理”的终点.
HttpModule和HttpHandler两者都是在HttpApplication.Init()函数调用的一部分中被载入并附加到调用链上.图6显示了不同的事件,它们是何时发生的以及它们影响管道的哪一部分.
图6-事件在ASP.NET http管道中流转的过程.HttpApplication对象的事件驱动请求在管道中流转.Http Module可以拦截这些事件并覆盖或者扩展现有的功能.
HttpContext, HttpModules 和 HttpHandlers
httpApplication它本身对发送给应用程序的数据一无所知-它只是一个通过事件来通讯的消息对象.它触发事件并通过HttpContext对象来向被调用函数传递消息.实际的当前请求的状态数据由前面提到的HttpContext对象维护.它提供了所有请求专有的数据并从进入管道开始到结束一直跟随请求.图7显示了ASP.NET管道中的流程.注意上下文对象(即HttpContext),这个从请求开始到结束一直都是你”朋友”的对象,可以在一个事件处理函数中保存信息并在以后的事件处理函数中取出.
一旦管道被启动,HttpApplication开始象图六那样一个个的触发事件.每个事件处理器被触发,如果事件被挂接,这些处理器将执行它们自己的任务.这个处理的主要任务是最终调用挂接到此特定请求的HttpHandler.处理器(handler)是ASP.NET请求的核心处理机制,通常也是所有应用程序级别的代码被执行的地方.记住ASP.NET页面和Web服务框架都是作为HttpHandler实现,这里也是处理请求的的核心之处.模块(module)趋向于成为一个传递给处理器(handler)的上下文的预处理或后处理器.ASP.NET中典型的默认处理器包括预处理的认证,缓存以及后处理中各种不同的编码机制.
有很多关于HttpHandler和HttpModule的可用信息,所以为了保持这篇文章在一个合理的长度,我将提供一个关于处理器的概要介绍.
HttpModule
当请求在管道中传递时,HttpApplicaion对象中一系列的事件被触发.我们已经看到这些事件在Global.asax中作为事件被发布.这种方法是特定于应用程序的,可能并不总是你想要的.如果你要建立一个通用的可用被插入任何Web应用程序的HttpApplication事件钩子,你可用使用HttpModule,这是可复用的,不需要特定语应用程序代码的,只需要web.config中的一个条目.
模块本质上是过滤器(fliter)-功能上类似于ISAPI过滤器,但是它工作在ASP.NET请求级别上.模块允许为每个通过HttpApplication对象的请求挂接事件.这些模块作为外部程序集中的类存贮.,在web.config文件中被配置,在应用程序启动时被载入.通过实现特定的接口和方法,模块被挂接到HttpApplication事件链上.多个HttpModule可用被挂接在相同的事件上,事件处理的顺序取决于它们在Web.config中声明的顺序.下面是在Web.config中处理器定义.
<configuration>
<system.web>
<httpModules>
<add name= "BasicAuthModule"
type="HttpHandlers.BasicAuth,WebStore" />
</httpModules>
</system.web>
</configuration>