HttpApplication资料讲解.doc

《HttpApplication资料讲解.doc》由会员分享，可在线阅读，更多相关《HttpApplication资料讲解.doc（25页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Good is good, but better carries it.精益求精，善益求善。HttpApplication-IIS在接到一个新的http请求后，最终会调用_isapi.dll的ISAPI扩展(特指IIS6.0环境，iis7.0的应用程序池默认为集成方式，相对有所变化)，然后传递到httpRuntimePipe(http运行时管道)，Asp.Net这时才开始运行(即HttpRunTime是Asp.Net真正的入口)，HttpRunTime会为每个应用自动创建一个HttpApplication的实例，而该实例中又包含以下属性:注1Application-相当于传统意义上asp时代的

2、application对象，通常用于定义一个应用的全局变量Context-HttpContext(上下文)类的实例【Asp.Net新增的】Modules-影响当前应用程序的HttpModule模块集合Request-类似于asp中的Request对象，通常用于接收一些特定的值(比如Request.Form或Request.QueryString)Response-类似于asp中的Response对象，通常用于向做页面输出指定内容(比如Resonse.Write)Server-类似于asp中的Server对象，通过它能获得一些服务端的信息(比如Server.MapPath)Session-类似于

3、asp中的Session对象User-用于获取用户认证相关的安全信息从上面的属性可以发现：很多其实在asp年代已在使用，只有Context,Modules,User这三个是Asp.Net新增的HttpApplication类除了具备注1的几个属性外，还有自己的方法，这里特别提一下Init方法和Dispose方法，这二个方法均可重载.它们的调用时机为:Init方法在Application_Start之后调用，而Dispose在Application_End之前调用，另外Application_Start在整个应用的生命周期内只激发一次(比如IIS启动或网站启动时)，类似的Application_

4、End也只有当应用程序关闭时被调用(比如IIS停止或网站停止时)除了Application_Start和Application_End方法，HttpApplication还提供了以下事件:这些事件包括前面提到的可重载的Init及Dispose方法，再加上Session对应的Session_Start与Session_End方法，均可直接在Global.ascx.cs中以Application_XXX的形式使用(因为Global.ascx.cs中定义的类Global本身就是继承自HttpApplication的)viewsourceprint?1publicclassGlobal:System.

5、Web.HttpApplication再来看一下相对asp而言，新增的Context,Modules,User这三个属性Context：Context即HttpContext类的实例，在几乎整个aspx页面生命周期中，Context上下文一直伴随着各个环节向下传递所以我们几乎可以在web应用中的任何环节，用HttpContext.Current来引用到当前的上下文实例，从HttpContext的定义上，还可以发现Context本身的属性中，又可以得到Application,ApplicationInstance,Profile,Response.Request.等对象的实例引用回想一下：vie

6、wsourceprint?01publicclassHandler1:IHttpHandler020304publicvoidProcessRequest(HttpContextcontext)0506context.Response.ContentType=text/plain;07context.Response.Write(HelloWorld);080910publicboolIsReusable1112get1314returnfalse;151617我们在使用一个ashx文件时，ProcessRequest方法便是把当前上下文传递进来，进而通过context得到Response对象

7、的引用，最终可以向页面输出任何想要的内容.Modules:每一个实现了IHttpModule接口的类，就可以被认为是Http模块组件，可以理解为http请求拦截器，拦截到http请求后，它能修改正在被处理的Context上下文，完事儿之后，再把控制权交还给管道，如果还有其它模块，则依次继续处理，直到所有Modules集合中的HttpModule都“爽”完为止(注：可怜的http请求就这样给各个httpModule轮X了)2.0默认内置了很多HttpModule，从Machine.Config文件中可以发现以下默认的内置模块:注2AnonymouseIdentification-为匿名用户分配一

8、个临时身份FileAuthorization-验证用户是否有请求文件的WindowsNT许可FormsAuthentication-窗体身份验证模块(如果没有这个模块,就无法以用户名/密码即FOrms方式验证)OutputCache-输出缓存模块PassportAuthentication-PassPort验证模块Profile-用户配置模块(如果没有它，中就无法使用Profile)RoleManager-角色管理SessionSate-会话状态模块UrlAuthorization-基于URL的身份验证模块WindowsAuthentication-Windows和IIS身份验证模块User：

9、如果您使用过2.0内置的Membership/Role机制来进行访问认证，就会对User对象感到很熟悉，比如：viewsourceprint?1if(HttpContext.Current.User.Identity.IsAuthenticated)23/用户登录过了.4我们常用它来判断当前浏览用户的登录状态，关于User类的更详细定义，可参见MSDN生命周期：最后再来回顾一下Asp.Net中Page页的生命周期，Page中定义了几个事件:总体上讲：一个ASPX页面被请求时，最终的生命周期就是由Page中定义的上述事件(还有一些可重载的回调方法)以及以前提到的HttpApplication类中

10、定义的事件(以相应的回调方法)共同触发或调用，最终叠加形成的一连串处理过程。如果先不考虑HttpApplication中的事件处理方法(即不考虑我们在Global.ascx.cs中定义的Application_XXX处理方法)，Page中的事件(方法)常规触发(调用)顺序为：01.Page_PreInit02.Page_Init03.Page_InitComplete04.Page_PreLoad05.Page_Load06.Page_LoadComplete07.Page_PreRender08.Page_SaveStateComplete09.Page_Unload这是在Page页面未回发

11、，且不考虑页面子控件的前提下正常的顺序，如果加入页面回发(比如在页面中放一个asp:Button，然后在Button的Click回发事件中加入处理函数)后，顺序稍微有些变化：01.Page_PreInit02.Page_Init03.Page_InitComplete04.Page_PreLoad05.Page_Load06.Button1_Click07.Page_LoadComplete08.Page_PreRender09.Page_SaveStateComplete10.Page_Unload不同的地方在于：回发事件Button1_Click在Page_Load后被触发.最后再把Htt

12、pApplication的事件考虑进来，看下叠加后的顺序，不过先别着急，我们先来看一种特殊情况，如果一个应用根目录下未设置默认页，这时直接浏览根目录，比如http:/localhost:2345/时，Globl.ascx.cs中定义的Application_XXX方法的调用顺序如下：2010-03-2815:01:39413Application_Start2010-03-2815:01:39491Init2010-03-2815:01:39491Application_BeginRequest2010-03-2815:01:39506Application_AuthenticateReque

13、st2010-03-2815:01:39506Application_PostAuthenticateRequest2010-03-2815:01:39506Application_AuthorizeRequest2010-03-2815:01:39522Application_PostAuthorizeRequest2010-03-2815:01:39522Application_ResolveRequestCache2010-03-2815:01:39522Application_PostResolveRequestCache2010-03-2815:01:39522Application

14、_PostMapRequestHandler2010-03-2815:01:39522Application_AcquireRequestState2010-03-2815:01:39537Application_PostAcquireRequestState2010-03-2815:01:39537Application_PreRequestHandlerExecute2010-03-2815:01:39553Application_Error2010-03-2815:01:39553Application_EndRequest2010-03-2815:01:39569Application

15、_PreSendRequestHeaders2010-03-2815:01:39569Application_PreSendRequestContent可以看到会触发Application_Error事件，即HttpRuntime认为这是一个错误.紧接着再浏览一个实际存在的页面，如果这时应用程序有严重错误，导致Application关闭(比如web.config配置错误)，调用的顺序如下:2010-03-2815:03:47704Application_BeginRequest2010-03-2815:03:47704Application_AuthenticateRequest2010-03

16、-2815:03:47766Application_PostAuthenticateRequest2010-03-2815:03:47766Application_AuthorizeRequest2010-03-2815:03:47766Application_PostAuthorizeRequest2010-03-2815:03:47766Application_ResolveRequestCache2010-03-2815:03:47783Application_PostResolveRequestCache2010-03-2815:03:48667Application_PostMapR

17、equestHandler2010-03-2815:03:48667Application_AcquireRequestState2010-03-2815:03:48683Application_PostAcquireRequestState2010-03-2815:03:48698Application_PreRequestHandlerExecute2010-03-2815:03:48745Page_PreInit2010-03-2815:04:02903Page_Unload2010-03-2815:04:02903Application_Error2010-03-2815:04:029

18、18Application_EndRequest2010-03-2815:04:02996Application_PreSendRequestHeaders2010-03-2815:04:02996Application_PreSendRequestContent2010-03-2815:04:03371Application_Disposed2010-03-2815:04:03371Dispose2010-03-2815:04:03386Application_End对比刚才的顺序，会发现Application_Start及Init没有再次被调用，也印证了文章前面提到的一些结论(Applic

19、ation_Start在整个应用生命周期内只触发一次)，而且从最后的三个输出能知道：应用程序关闭时Application_Disposed,Dispose,Application_End按顺序调用.再重新浏览(指webServer重启)一下正常访问的页面，在不出错也不回发的情况下，顺序如下:2010-03-2815:08:11513Application_Start2010-03-2815:08:11591Init2010-03-2815:08:11591Application_BeginRequest2010-03-2815:08:11591Application_AuthenticateR

20、equest2010-03-2815:08:11591Application_PostAuthenticateRequest2010-03-2815:08:11606Application_AuthorizeRequest2010-03-2815:08:11606Application_PostAuthorizeRequest2010-03-2815:08:11606Application_ResolveRequestCache2010-03-2815:08:11606Application_PostResolveRequestCache2010-03-2815:08:11622Applica

21、tion_PostMapRequestHandler2010-03-2815:08:11637Application_EndRequest2010-03-2815:08:11637Application_PreSendRequestHeaders2010-03-2815:08:11637Application_PreSendRequestContent2010-03-2815:08:11637Application_BeginRequest2010-03-2815:08:11637Application_AuthenticateRequest2010-03-2815:08:11653Appli

22、cation_PostAuthenticateRequest2010-03-2815:08:11653Application_AuthorizeRequest2010-03-2815:08:11653Application_PostAuthorizeRequest2010-03-2815:08:11653Application_ResolveRequestCache2010-03-2815:08:11653Application_PostResolveRequestCache2010-03-2815:08:11653Application_PostMapRequestHandler2010-0

23、3-2815:08:11653Session_Start2010-03-2815:08:11653Application_AcquireRequestState2010-03-2815:08:11653Application_PostAcquireRequestState2010-03-2815:08:11653Application_PreRequestHandlerExecute2010-03-2815:08:11669Page_PreInit2010-03-2815:08:11684Page_Init2010-03-2815:08:11684Page_InitComplete2010-0

24、3-2815:08:11684Page_PreLoad2010-03-2815:08:11684Page_Load2010-03-2815:08:11684Page_LoadComplete2010-03-2815:08:11684Page_PreRender2010-03-2815:08:11684Page_SaveStateComplete2010-03-2815:08:11700Page_Unload2010-03-2815:08:11700Application_PostRequestHandlerExecute2010-03-2815:08:11700Application_Rele

25、aseRequestState2010-03-2815:08:11700Application_PostReleaseRequestState2010-03-2815:08:11700Application_UpdateRequestCache2010-03-2815:08:11700Application_PostUpdateRequestCache2010-03-2815:08:11700Application_EndRequest2010-03-2815:08:11700Application_PreSendRequestHeaders2010-03-2815:08:11700Appli

26、cation_PreSendRequestContent2010-03-2815:08:11793Application_BeginRequest2010-03-2815:08:11793Application_AuthenticateRequest2010-03-2815:08:11793Application_PostAuthenticateRequest2010-03-2815:08:11793Application_AuthorizeRequest2010-03-2815:08:11793Application_PostAuthorizeRequest2010-03-2815:08:1

27、1793Application_ResolveRequestCache2010-03-2815:08:11793Application_PostResolveRequestCache2010-03-2815:08:11809Application_PostMapRequestHandler2010-03-2815:08:11809Application_AcquireRequestState2010-03-2815:08:11809Application_PostAcquireRequestState2010-03-2815:08:11809Application_PreRequestHand

28、lerExecute2010-03-2815:08:11825Application_PostRequestHandlerExecute2010-03-2815:08:11825Application_ReleaseRequestState2010-03-2815:08:11840Application_PostReleaseRequestState2010-03-2815:08:11949Application_UpdateRequestCache2010-03-2815:08:11949Application_PostUpdateRequestCache2010-03-2815:08:11

29、965Application_EndRequest2010-03-2815:08:11981Application_PreSendRequestHeaders2010-03-2815:08:11981Application_PreSendRequestContent哇！原来一个页面访问下来，会调用到这么多的方法，怪不得很多高并发的大型网站，通常都要自己写一个精减的HttpHandler用来取代Page做为基类，以期望获得更好的性能更准确的页面生命周期解释，请查阅下面的文档，这是msdn官方网站对于Asp.Net页面生命周期的权威解释文中测试所用的源代码:(用vs2010RC打开)作者：菩提树下的杨过出处：本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。-