《温故而知新：HttpApplicationHttpModuleHttpContext及AspNet页生命周期》由会员分享，可在线阅读，更多相关《温故而知新：HttpApplicationHttpModuleHttpContext及AspNet页生命周期（14页珍藏版）》请在金锄头文库上搜索。
1、温故而知新：HttpApplication,HttpModule,HttpContext及Asp.Net页生命周期 作者： 日期：IIS在接到一个新的http请求后，最终会调用_isapi.dll的ISAPI扩展(特指IIS6.0环境，iis7.0的应用程序池默认为集成方式，相对有所变化)，然后传递到httpRuntime Pipe(http运行时管道)，Asp.Net这时才开始运行(即HttpRunTime是Asp.Net真正的入口)，HttpRunTime会为每个应用自动创建一个HttpApplication的实例，而该实例中又包含以下属性:注1Application -相当于传统意义上a
2、sp时代的application对象，通常用于定义一个应用的全局变量Context -HttpContext(上下文)类的实例【Asp.Net新增的】Modules -影响当前应用程序的HttpModule模块集合Request -类似于asp中的Request对象，通常用于接收一些特定的值(比如Request.Form或Request.QueryString)Response -类似于asp中的Response对象，通常用于向做页面输出指定内容(比如Resonse.Write)Server -类似于asp中的Server对象，通过它能获得一些服务端的信息(比如Server.MapPath)S
3、ession -类似于asp中的Session对象User -用于获取用户认证相关的安全信息从上面的属性可以发现：很多其实在asp年代已在使用，只有Context,Modules,User这三个是Asp.Net新增的HttpApplication类除了具备注1的几个属性外，还有自己的方法，这里特别提一下Init方法和Dispose方法，这二个方法均可重载.它们的调用时机为:Init方法在Application_Start之后调用，而Dispose在Application_End之前调用，另外Application_Start在整个应用的生命周期内只激发一次(比如IIS启动或网站启动时)，类似的
4、Application_End也只有当应用程序关闭时被调用(比如IIS停止或网站停止时)除了Application_Start和Application_End方法，HttpApplication还提供了以下事件:这些事件包括前面提到的可重载的Init及Dispose方法，再加上Session对应的Session_Start与Session_End方法，均可直接在Global.ascx.cs中以Application_XXX的形式使用(因为Global.ascx.cs中定义的类Global本身就是继承自HttpApplication的)view source print?1public clas
5、s Global : System.Web.HttpApplication再来看一下相对asp而言，新增的Context,Modules,User这三个属性Context：Context即HttpContext类的实例，在几乎整个aspx页面生命周期中，Context上下文一直伴随着各个环节向下传递所以我们几乎可以在web应用中的任何环节，用HttpContext.Current来引用到当前的上下文实例，从HttpContext的定义上，还可以发现Context本身的属性中，又可以得到Application,ApplicationInstance,Profile,Response.Reques
6、t.等对象的实例引用回想一下：view source print?01public class Handler1 : IHttpHandler 02 0304public void ProcessRequest(HttpContext context) 05 06context.Response.ContentType = text/plain; 07context.Response.Write(Hello World); 08 0910public bool IsReusable 11 12get13 14return false; 15 16 17我们在使用一个ashx文件时，Proces
7、sRequest方法便是把当前上下文传递进来，进而通过context得到Response对象的引用，最终可以向页面输出任何想要的内容.Modules:每一个实现了IHttpModule接口的类，就可以被认为是Http模块组件，可以理解为http请求拦截器，拦截到http请求后，它能修改正在被处理的Context上下文，完事儿之后，再把控制权交还给管道，如果还有其它模块，则依次继续处理，直到所有Modules集合中的HttpModule都“爽”完为止(注：可怜的http请求就这样给各个httpModule轮X了)2.0默认内置了很多HttpModule，从Machine.Config文件中可以发
8、现以下默认的内置模块:注2AnonymouseIdentification -为匿名用户分配一个临时身份FileAuthorization -验证用户是否有请求文件的Windows NT许可FormsAuthentication -窗体身份验证模块(如果没有这个模块,就无法以用户名/密码即FOrms方式验证)OutputCache -输出缓存模块PassportAuthentication -PassPort验证模块Profile -用户配置模块(如果没有它，中就无法使用Profile)RoleManager -角色管理SessionSate -会话状态模块UrlAuthorization -
9、基于URL的身份验证模块WindowsAuthentication -Windows和IIS身份验证模块User：如果您使用过2.0内置的Membership/Role机制来进行访问认证，就会对User对象感到很熟悉，比如：view source print?1if (HttpContext.Current.User.Identity.IsAuthenticated) 2 3/用户登录过了. 4我们常用它来判断当前浏览用户的登录状态，关于User类的更详细定义，可参见MSDN生命周期：最后再来回顾一下Asp.Net中Page页的生命周期，Page中定义了几个事件:总体上讲：一个ASPX页面被请
10、求时，最终的生命周期就是由Page中定义的上述事件(还有一些可重载的回调方法)以及以前提到的HttpApplication类中定义的事件(以相应的回调方法)共同触发或调用，最终叠加形成的一连串处理过程。如果先不考虑HttpApplication中的事件处理方法(即不考虑我们在Global.ascx.cs中定义的Application_XXX处理方法)，Page中的事件(方法)常规触发(调用)顺序为：01.Page_PreInit02.Page_Init03.Page_InitComplete04.Page_PreLoad05.Page_Load06.Page_LoadComplete07.Pa
11、ge_PreRender08.Page_SaveStateComplete09.Page_Unload这是在Page页面未回发，且不考虑页面子控件的前提下正常的顺序，如果加入页面回发(比如在页面中放一个asp:Button，然后在Button的Click回发事件中加入处理函数)后，顺序稍微有些变化：01.Page_PreInit02.Page_Init03.Page_InitComplete04.Page_PreLoad05.Page_Load06.Button1_Click07.Page_LoadComplete08.Page_PreRender09.Page_SaveStateComple
12、te10.Page_Unload不同的地方在于：回发事件Button1_Click在Page_Load后被触发.最后再把HttpApplication的事件考虑进来，看下叠加后的顺序，不过先别着急，我们先来看一种特殊情况，如果一个应用根目录下未设置默认页，这时直接浏览根目录，比如http:/localhost:2345/ 时，Globl.ascx.cs中定义的Application_XXX方法的调用顺序如下：2010-03-28 15:01:39 413Application_Start2010-03-28 15:01:39 491Init2010-03-28 15:01:39 491Appl
13、ication_BeginRequest2010-03-28 15:01:39 506Application_AuthenticateRequest2010-03-28 15:01:39 506Application_PostAuthenticateRequest2010-03-28 15:01:39 506Application_AuthorizeRequest2010-03-28 15:01:39 522Application_PostAuthorizeRequest2010-03-28 15:01:39 522Application_ResolveRequestCache2010-03-
14、28 15:01:39 522Application_PostResolveRequestCache2010-03-28 15:01:39 522Application_PostMapRequestHandler2010-03-28 15:01:39 522Application_AcquireRequestState2010-03-28 15:01:39 537Application_PostAcquireRequestState2010-03-28 15:01:39 537Application_PreRequestHandlerExecute2010-03-28 15:01:39 553Application_Error2010-03-28 15:01:39 553Application_E
