温故而知新:HttpApplication,HttpModule,HttpContext及Asp.Net页生命周期

简介:

IIS在接到一个新的http请求后,最终会调用asp.net_isapi.dll的ISAPI扩展(特指IIS6.0环境,iis7.0的应用程序池默认为集成方式,相对有所变化),然后传递到httpRuntime Pipe(http运行时管道),Asp.Net这时才开始运行(即HttpRunTime是Asp.Net真正的入口),HttpRunTime会为每个asp.net应用自动创建一个HttpApplication的实例,而该实例中又包含以下属性:

注1

Application -->相当于传统意义上asp时代的application对象,通常用于定义一个asp.net应用的全局变量

Context -->HttpContext(上下文)类的实例【Asp.Net新增的】

Modules -->影响当前应用程序的HttpModule模块集合

Request -->类似于asp中的Request对象,通常用于接收一些特定的值(比如Request.Form或Request.QueryString)

Response -->类似于asp中的Response对象,通常用于向做页面输出指定内容(比如Resonse.Write)

Server -->类似于asp中的Server对象,通过它能获得一些服务端的信息(比如Server.MapPath)

Session -->类似于asp中的Session对象

User -->用于获取用户认证相关的安全信息

 

从上面的属性可以发现:很多其实在asp年代已在使用,只有Context,Modules,User这三个是Asp.Net新增的

 

HttpApplication类除了具备"注1"的几个属性外,还有自己的方法,这里特别提一下Init方法和Dispose方法,这二个方法均可重载.

 

它们的调用时机为:

Init方法在Application_Start之后调用,而Dispose在Application_End之前调用,另外Application_Start在整个asp.net应用的生命周期内只激发一次(比如IIS启动或网站启动时),类似的Application_End也只有当asp.net应用程序关闭时被调用(比如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

public class Global : System.Web.HttpApplication

再来看一下相对asp而言,新增的Context,Modules,User这三个属性

 

Context

Context即HttpContext类的实例,在几乎整个aspx页面生命周期中,Context上下文一直伴随着各个环节向下传递

 

所以我们几乎可以在web应用中的任何环节,用HttpContext.Current来引用到当前的上下文实例,从HttpContext的定义上,还可以发现Context本身的属性中,又可以得到Application,ApplicationInstance,Profile,Response.Request...等对象的实例引用

 

回想一下:

view source

/// <summary>
///Handler1 的摘要说明
/// </summary>
public class Handler1 : IHttpHandler 
{
    public void ProcessRequest(HttpContext context)
    {
        context.Response.ContentType = "text/plain";
        context.Response.Write("Hello World");
    }
    public bool IsReusable
    {
        get
        {
            return false;
        }
    }
}

我们在使用一个ashx文件时,ProcessRequest方法便是把当前上下文传递进来,进而通过context得到Response对象的引用,最终可以向页面输出任何想要的内容.

 

Modules:

每一个实现了IHttpModule接口的类,就可以被认为是Http模块组件,可以理解为http请求拦截器,拦截到http请求后,它能修改正在被处理的Context上下文,完事儿之后,再把控制权交还给管道,如果还有其它模块,则依次继续处理,直到所有Modules集合中的HttpModule都“爽”完为止(注:可怜的http请求就这样给各个httpModule轮X了)

asp.net2.0默认内置了很多HttpModule,从Machine.Config文件中可以发现以下默认的内置模块:

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

 

User

如果您使用过asp.net2.0内置的Membership/Role机制来进行访问认证,就会对User对象感到很熟悉,比如:

view source

if (HttpContext.Current.User.Identity.IsAuthenticated)
{
  
 //用户登录过了...
}

我们常用它来判断当前浏览用户的登录状态,关于User类的更详细定义,可参见MSDN


生命周期:

最后再来回顾一下Asp.Net中Page页的生命周期,Page中定义了几个事件:

总体上讲:一个ASPX页面被请求时,最终的生命周期就是由Page中定义的上述事件(还有一些可重载的回调方法)以及以前提到的HttpApplication类中定义的事件(以相应的回调方法)共同触发或调用,最终叠加形成的一连串处理过程。

如果先不考虑HttpApplication中的事件处理方法(即不考虑我们在Global.ascx.cs中定义的Application_XXX处理方法),Page中的事件(方法)常规触发(调用)顺序为:

01.Page_PreInit

02.Page_Init

03.Page_InitComplete

04.Page_PreLoad

05.Page_Load

06.Page_LoadComplete

07.Page_PreRender

08.Page_SaveStateComplete

09.Page_Unload

这是在Page页面未回发,且不考虑页面子控件的前提下正常的顺序,如果加入页面回发(比如在页面中放一个asp:Button,然后在Button的Click回发事件中加入处理函数)后,顺序稍微有些变化:

01.Page_PreInit

02.Page_Init

03.Page_InitComplete

04.Page_PreLoad

05.Page_Load

06.Button1_Click

07.Page_LoadComplete

08.Page_PreRender

09.Page_SaveStateComplete

10.Page_Unload

不同的地方在于:回发事件Button1_Click在Page_Load后被触发.

最后再把HttpApplication的事件考虑进来,看下叠加后的顺序,不过先别着急,我们先来看一种特殊情况,如果一个asp.net应用根目录下未设置默认页,这时直接浏览根目录,比如http://localhost:2345/ 时,Globl.ascx.cs中定义的Application_XXX方法的调用顺序如下:
2011-05-03 15:01:39 413 Application_Start

2011-05-03 15:01:39 491 Init

2011-05-03 15:01:39 491 Application_BeginRequest

2011-05-03 15:01:39 506 Application_AuthenticateRequest

2011-05-03 15:01:39 506 Application_PostAuthenticateRequest

2011-05-03 15:01:39 506 Application_AuthorizeRequest

2011-05-03 15:01:39 522 Application_PostAuthorizeRequest

2011-05-03 15:01:39 522 Application_ResolveRequestCache

2011-05-03 15:01:39 522 Application_PostResolveRequestCache

2011-05-03 15:01:39 522 Application_PostMapRequestHandler

2011-05-03 15:01:39 522 Application_AcquireRequestState

2011-05-03 15:01:39 537 Application_PostAcquireRequestState

2011-05-03 15:01:39 537 Application_PreRequestHandlerExecute

2011-05-03 15:01:39 553 Application_Error

2011-05-03 15:01:39 553 Application_EndRequest

2011-05-03 15:01:39 569 Application_PreSendRequestHeaders

2011-05-03 15:01:39 569 Application_PreSendRequestContent

可以看到会触发Application_Error事件,即HttpRuntime认为这是一个错误.

紧接着再浏览一个实际存在的页面,如果这时应用程序有严重错误,导致Application关闭(比如web.config配置错误),调用的顺序如下:
2011-05-03 15:03:47 704 Application_BeginRequest

2011-05-03 15:03:47 704 Application_AuthenticateRequest

2011-05-03 15:03:47 766 Application_PostAuthenticateRequest

2011-05-03 15:03:47 766 Application_AuthorizeRequest

2011-05-03 15:03:47 766 Application_PostAuthorizeRequest

2011-05-03 15:03:47 766 Application_ResolveRequestCache

2011-05-03 15:03:47 783 Application_PostResolveRequestCache

2011-05-03 15:03:48 667 Application_PostMapRequestHandler

2011-05-03 15:03:48 667 Application_AcquireRequestState

2011-05-03 15:03:48 683 Application_PostAcquireRequestState

2011-05-03 15:03:48 698 Application_PreRequestHandlerExecute

2011-05-03 15:03:48 745 Page_PreInit

2011-05-03 15:04:02 903 Page_Unload

2011-05-03 15:04:02 903 Application_Error

2011-05-03 15:04:02 918 Application_EndRequest

2011-05-03 15:04:02 996 Application_PreSendRequestHeaders

2011-05-03 15:04:02 996 Application_PreSendRequestContent

2011-05-03 15:04:03 371 Application_Disposed

2011-05-03 15:04:03 371 Dispose

2011-05-03 15:04:03 386 Application_End

对比刚才的顺序,会发现Application_Start及Init没有再次被调用,也印证了文章前面提到的一些结论(Application_Start在整个asp.net应用生命周期内只触发一次),而且从最后的三个输出能知道:应用程序关闭时Application_Disposed,Dispose,Application_End按顺序调用.

再"重新"浏览(指web Server重启)一下正常访问的页面,在不出错也不回发的情况下,顺序如下:
2011-05-03 15:08:11 513 Application_Start

2011-05-03 15:08:11 591 Init

2011-05-03 15:08:11 591 Application_BeginRequest

2011-05-03 15:08:11 591 Application_AuthenticateRequest

2011-05-03 15:08:11 591 Application_PostAuthenticateRequest

2011-05-03 15:08:11 606 Application_AuthorizeRequest

2011-05-03 15:08:11 606 Application_PostAuthorizeRequest

2011-05-03 15:08:11 606 Application_ResolveRequestCache

2011-05-03 15:08:11 606 Application_PostResolveRequestCache

2011-05-03 15:08:11 622 Application_PostMapRequestHandler

2011-05-03 15:08:11 637 Application_EndRequest

2011-05-03 15:08:11 637 Application_PreSendRequestHeaders

2011-05-03 15:08:11 637 Application_PreSendRequestContent

2011-05-03 15:08:11 637 Application_BeginRequest

2011-05-03 15:08:11 637 Application_AuthenticateRequest

2011-05-03 15:08:11 653 Application_PostAuthenticateRequest

2011-05-03 15:08:11 653 Application_AuthorizeRequest

2011-05-03 15:08:11 653 Application_PostAuthorizeRequest

2011-05-03 15:08:11 653 Application_ResolveRequestCache

2011-05-03 15:08:11 653 Application_PostResolveRequestCache

2011-05-03 15:08:11 653 Application_PostMapRequestHandler

2011-05-03 15:08:11 653 Session_Start

2011-05-03 15:08:11 653 Application_AcquireRequestState

2011-05-03 15:08:11 653 Application_PostAcquireRequestState

2011-05-03 15:08:11 653 Application_PreRequestHandlerExecute

2011-05-03 15:08:11 669 Page_PreInit

2011-05-03 15:08:11 684 Page_Init

2011-05-03 15:08:11 684 Page_InitComplete

2011-05-03 15:08:11 684 Page_PreLoad

2011-05-03 15:08:11 684 Page_Load

2011-05-03 15:08:11 684 Page_LoadComplete

2011-05-03 15:08:11 684 Page_PreRender

2011-05-03 15:08:11 684 Page_SaveStateComplete

2011-05-03 15:08:11 700 Page_Unload

2011-05-03 15:08:11 700 Application_PostRequestHandlerExecute

2011-05-03 15:08:11 700 Application_ReleaseRequestState

2011-05-03 15:08:11 700 Application_PostReleaseRequestState

2011-05-03 15:08:11 700 Application_UpdateRequestCache

2011-05-03 15:08:11 700 Application_PostUpdateRequestCache

2011-05-03 15:08:11 700 Application_EndRequest

2011-05-03 15:08:11 700 Application_PreSendRequestHeaders

2011-05-03 15:08:11 700 Application_PreSendRequestContent

2011-05-03 15:08:11 793 Application_BeginRequest

2011-05-03 15:08:11 793 Application_AuthenticateRequest

2011-05-03 15:08:11 793 Application_PostAuthenticateRequest

2011-05-03 15:08:11 793 Application_AuthorizeRequest

2011-05-03 15:08:11 793 Application_PostAuthorizeRequest

2011-05-03 15:08:11 793 Application_ResolveRequestCache

2011-05-03 15:08:11 793 Application_PostResolveRequestCache

2011-05-03 15:08:11 809 Application_PostMapRequestHandler

2011-05-03 15:08:11 809 Application_AcquireRequestState

2011-05-03 15:08:11 809 Application_PostAcquireRequestState

2011-05-03 15:08:11 809 Application_PreRequestHandlerExecute

2011-05-03 15:08:11 825 Application_PostRequestHandlerExecute

2011-05-03 15:08:11 825 Application_ReleaseRequestState

2011-05-03 15:08:11 840 Application_PostReleaseRequestState

2011-05-03 15:08:11 949 Application_UpdateRequestCache

2011-05-03 15:08:11 949 Application_PostUpdateRequestCache

2011-05-03 15:08:11 965 Application_EndRequest

2011-05-03 15:08:11 981 Application_PreSendRequestHeaders

2011-05-03 15:08:11 981 Application_PreSendRequestContent

哇!原来一个页面访问下来,会调用到这么多的方法,怪不得很多高并发的大型网站,通常都要自己写一个精减的HttpHandler用来取代Page做为基类,以期望获得更好的性能

更准确的页面生命周期解释,请查阅下面的文档,这是msdn官方网站对于Asp.Net页面生命周期的权威解释

文中源码



本文转自左正博客园博客,原文链接:http://www.cnblogs.com/soundcode/archive/2011/05/05/2038296.html,如需转载请自行联系原作者

目录
相关文章
|
前端开发 .NET 开发框架
ASP.NET Core 2 学习笔记(二)生命周期
原文:ASP.NET Core 2 学习笔记(二)生命周期 要了解程序的运行原理,就要先知道程序的进入点及生命周期。以往ASP.NET MVC的启动方式,是继承 HttpApplication 作为网站开始的进入点,而ASP.NET Core 改变了网站的启动方式,变得比较像是 Console Application。
1079 0
|
前端开发 .NET
ASP.NET MVC5请求管道和生命周期
请求处理管道 请求管道是一些用于处理HTTP请求的模块组合,在ASP.NET中,请求管道有两个核心组件:IHttpModule和IHttpHandler。所有的HTTP请求都会进入IHttpHandler,有IHttpHandler进行最终的处理,而IHttpModule通过订阅HttpApplication对象中的事件,可以在IHttpHandler对HTTP请求进行处理之前对请求进行预处理或IHttpHandler对HTTP请求处理之后进行再次处理。
1236 0
|
.NET 开发框架 存储
[译] ASP.NET 生命周期 – ASP.NET 请求生命周期(三)
使用特殊方法处理请求生命周期事件 为了在全局应用类中处理这些事件,我们会创建一个名称以 Application_ 开头,以事件名称结尾的方法,比如 Application_BeginRequest。举个例子,就像 Application_Start 和 Application_End 方法,ASP.NET 框架就会在事件触发的时候找到这些函数并触发它。
837 0
|
Web App开发 前端开发 .NET
[译] ASP.NET 生命周期 – ASP.NET 请求生命周期(二)
ASP.NET 请求生命周期 全局应用类也可以用来跟踪每个独立请求的生命周期,包括请求从 ASP.NET 平台传递到 MVC 框架。ASP.NET 框架会创建一个定义在 Global.asax 文件中的 MvcApplication 类的实例,并使用它当中定义的事件来引导请求,直到产生响应并发送到浏览器中。
1212 0
|
Web App开发 前端开发 .NET
[译] ASP.NET 生命周期 – ASP.NET 应用生命周期(一)
概述 ASP.NET 平台定义了两个非常重要的生命周期。第一个是 应用生命周期  (application life cycle),用来追踪应用从启动的那一刻到终止的那一刻。另一个就是 请求生命周期 (request life cycle),它定义了 HTTP 请求在 ASP.NET 平台中首次接收到,到最终响应发出之间的路径。
1217 0
|
.NET 程序员 开发框架
asp.net生命周期
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq1010885678/article/details/37540769 当用户起一个请求到服务器,服务器接收到请求并将该页面返回给浏览器。
893 0
|
.NET
ASP.NET页面生命周期与应用程序生命周期
ASP.NET页面生命周期与应用程序生命周期 页面生命周期 页面生命周期执行一系列步骤:页面的初始化、实例化控件、还原和维护状态、运行事件处理程序代码、呈现。
821 0
|
.NET 开发者 开发框架
记不住ASP.NET页面生命周期的苦恼
介绍 对于ASP.NET开发者,理解ASP.NET的页面生命周期是非常重要的。主要是为了搞明白在哪里放置特定的方法和在何时设置各种页面属性。但是记忆和理解页面生命周期里提供的事件处理方法(method)非常困难。
869 0