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的)

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...等对象的实例引用

回想一下：

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对象感到很熟悉，比如：

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方法的调用顺序如下：
2010-03-28 15:01:39 413 application_start

2010-03-28 15:01:39 491 init

2010-03-28 15:01:39 491 application_beginrequest

2010-03-28 15:01:39 506 application_authenticaterequest

2010-03-28 15:01:39 506 application_postauthenticaterequest

2010-03-28 15:01:39 506 application_authorizerequest

2010-03-28 15:01:39 522 application_postauthorizerequest

2010-03-28 15:01:39 522 application_resolverequestcache

2010-03-28 15:01:39 522 application_postresolverequestcache

2010-03-28 15:01:39 522 application_postmaprequesthandler

2010-03-28 15:01:39 522 application_acquirerequeststate

2010-03-28 15:01:39 537 application_postacquirerequeststate

2010-03-28 15:01:39 537 application_prerequesthandlerexecute

2010-03-28 15:01:39 553 application_error

2010-03-28 15:01:39 553 application_endrequest

2010-03-28 15:01:39 569 application_presendrequestheaders

2010-03-28 15:01:39 569 application_presendrequestcontent

可以看到会触发application_error事件，即httpruntime认为这是一个错误.

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

2010-03-28 15:03:47 704 application_authenticaterequest

2010-03-28 15:03:47 766 application_postauthenticaterequest

2010-03-28 15:03:47 766 application_authorizerequest

2010-03-28 15:03:47 766 application_postauthorizerequest

2010-03-28 15:03:47 766 application_resolverequestcache

2010-03-28 15:03:47 783 application_postresolverequestcache

2010-03-28 15:03:48 667 application_postmaprequesthandler

2010-03-28 15:03:48 667 application_acquirerequeststate

2010-03-28 15:03:48 683 application_postacquirerequeststate

2010-03-28 15:03:48 698 application_prerequesthandlerexecute

2010-03-28 15:03:48 745 page_preinit

2010-03-28 15:04:02 903 page_unload

2010-03-28 15:04:02 903 application_error

2010-03-28 15:04:02 918 application_endrequest

2010-03-28 15:04:02 996 application_presendrequestheaders

2010-03-28 15:04:02 996 application_presendrequestcontent

2010-03-28 15:04:03 371 application_disposed

2010-03-28 15:04:03 371 dispose

2010-03-28 15:04:03 386 application_end

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

再"重新"浏览(指web server重启)一下正常访问的页面，在不出错也不回发的情况下，顺序如下:
2010-03-28 15:08:11 513 application_start

2010-03-28 15:08:11 591 init

2010-03-28 15:08:11 591 application_beginrequest

2010-03-28 15:08:11 591 application_authenticaterequest

2010-03-28 15:08:11 591 application_postauthenticaterequest

2010-03-28 15:08:11 606 application_authorizerequest

2010-03-28 15:08:11 606 application_postauthorizerequest

2010-03-28 15:08:11 606 application_resolverequestcache

2010-03-28 15:08:11 606 application_postresolverequestcache

2010-03-28 15:08:11 622 application_postmaprequesthandler

2010-03-28 15:08:11 637 application_endrequest

2010-03-28 15:08:11 637 application_presendrequestheaders

2010-03-28 15:08:11 637 application_presendrequestcontent

2010-03-28 15:08:11 637 application_beginrequest

2010-03-28 15:08:11 637 application_authenticaterequest

2010-03-28 15:08:11 653 application_postauthenticaterequest

2010-03-28 15:08:11 653 application_authorizerequest

2010-03-28 15:08:11 653 application_postauthorizerequest

2010-03-28 15:08:11 653 application_resolverequestcache

2010-03-28 15:08:11 653 application_postresolverequestcache

2010-03-28 15:08:11 653 application_postmaprequesthandler

2010-03-28 15:08:11 653 session_start

2010-03-28 15:08:11 653 application_acquirerequeststate

2010-03-28 15:08:11 653 application_postacquirerequeststate

2010-03-28 15:08:11 653 application_prerequesthandlerexecute

2010-03-28 15:08:11 669 page_preinit

2010-03-28 15:08:11 684 page_init

2010-03-28 15:08:11 684 page_initcomplete

2010-03-28 15:08:11 684 page_preload

2010-03-28 15:08:11 684 page_load

2010-03-28 15:08:11 684 page_loadcomplete

2010-03-28 15:08:11 684 page_prerender

2010-03-28 15:08:11 684 page_savestatecomplete

2010-03-28 15:08:11 700 page_unload

2010-03-28 15:08:11 700 application_postrequesthandlerexecute

2010-03-28 15:08:11 700 application_releaserequeststate

2010-03-28 15:08:11 700 application_postreleaserequeststate

2010-03-28 15:08:11 700 application_updaterequestcache

2010-03-28 15:08:11 700 application_postupdaterequestcache

2010-03-28 15:08:11 700 application_endrequest

2010-03-28 15:08:11 700 application_presendrequestheaders

2010-03-28 15:08:11 700 application_presendrequestcontent

2010-03-28 15:08:11 793 application_beginrequest

2010-03-28 15:08:11 793 application_authenticaterequest

2010-03-28 15:08:11 793 application_postauthenticaterequest

2010-03-28 15:08:11 793 application_authorizerequest

2010-03-28 15:08:11 793 application_postauthorizerequest

2010-03-28 15:08:11 793 application_resolverequestcache

2010-03-28 15:08:11 793 application_postresolverequestcache

2010-03-28 15:08:11 809 application_postmaprequesthandler

2010-03-28 15:08:11 809 application_acquirerequeststate

2010-03-28 15:08:11 809 application_postacquirerequeststate

2010-03-28 15:08:11 809 application_prerequesthandlerexecute

2010-03-28 15:08:11 825 application_postrequesthandlerexecute

2010-03-28 15:08:11 825 application_releaserequeststate

2010-03-28 15:08:11 840 application_postreleaserequeststate

2010-03-28 15:08:11 949 application_updaterequestcache

2010-03-28 15:08:11 949 application_postupdaterequestcache

2010-03-28 15:08:11 965 application_endrequest

2010-03-28 15:08:11 981 application_presendrequestheaders

2010-03-28 15:08:11 981 application_presendrequestcontent

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

最后：我们在做网站开发时，不可能只用到page页，很多时候还会用到usercontrol（用户自定义控件），先看下它的继承关系，比如我们创建了一个testusercontrol的用户控件

testusercontrol --> usercontrol ---> templatecontrol --> control

最终在control类的定义下，可以看到

这似乎表明用户控件中，应该有page_init,page_load,page_unload...等事件，通常我们只用到init,load事件，如果加入一个用户控件后，整个生命周期就更复杂了：

2010-06-12 15:35:28 042 application_start

2010-06-12 15:35:28 072 init

2010-06-12 15:35:28 072 application_beginrequest

2010-06-12 15:35:28 082 application_authenticaterequest

2010-06-12 15:35:28 082 application_postauthenticaterequest

2010-06-12 15:35:28 092 application_authorizerequest

2010-06-12 15:35:28 102 application_postauthorizerequest

2010-06-12 15:35:28 102 application_resolverequestcache

2010-06-12 15:35:28 112 application_postresolverequestcache

2010-06-12 15:35:28 122 application_postmaprequesthandler

2010-06-12 15:35:28 142 application_endrequest

2010-06-12 15:35:28 142 application_presendrequestheaders

2010-06-12 15:35:28 142 application_presendrequestcontent

2010-06-12 15:35:28 152 application_beginrequest

2010-06-12 15:35:28 152 application_authenticaterequest

2010-06-12 15:35:28 162 application_postauthenticaterequest

2010-06-12 15:35:28 162 application_authorizerequest

2010-06-12 15:35:28 162 application_postauthorizerequest

2010-06-12 15:35:28 172 application_resolverequestcache

2010-06-12 15:35:28 172 application_postresolverequestcache

2010-06-12 15:35:28 172 application_postmaprequesthandler

2010-06-12 15:35:28 172 session_start

2010-06-12 15:35:28 172 application_acquirerequeststate

2010-06-12 15:35:28 182 application_postacquirerequeststate

2010-06-12 15:35:28 182 application_prerequesthandlerexecute

2010-06-12 15:35:28 192 page_preinit

2010-06-12 15:35:28 192 testusercontrol.page_init

2010-06-12 15:35:28 202 page_init

2010-06-12 15:35:28 202 testusercontrol.testproperty.set

2010-06-12 15:35:28 202 page_initcomplete

2010-06-12 15:35:28 202 page_preload

2010-06-12 15:35:28 202 page_load

2010-06-12 15:35:28 202 testusercontrol.page_load

2010-06-12 15:35:28 202 testusercontrol.showdata()

2010-06-12 15:35:28 212 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 212 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 212 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 212 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 212 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 222 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 222 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 222 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 222 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 222 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 232 testusercontrol.repeater1.itemdatabound()

2010-06-12 15:35:28 232 page_loadcomplete

2010-06-12 15:35:28 232 page_prerender

2010-06-12 15:35:28 232 testusercontrol.page_prerender

2010-06-12 15:35:28 242 page_savestatecomplete

2010-06-12 15:35:28 242 testusercontrol.page_unload

2010-06-12 15:35:28 252 page_unload

2010-06-12 15:35:28 252 application_postrequesthandlerexecute

2010-06-12 15:35:28 252 application_releaserequeststate

2010-06-12 15:35:28 252 application_postreleaserequeststate

2010-06-12 15:35:28 262 application_updaterequestcache

2010-06-12 15:35:28 262 application_postupdaterequestcache

2010-06-12 15:35:28 262 application_endrequest

2010-06-12 15:35:28 272 application_presendrequestheaders

2010-06-12 15:35:28 272 application_presendrequestcontent

2010-06-12 15:35:28 282 application_beginrequest

2010-06-12 15:35:28 292 application_authenticaterequest

2010-06-12 15:35:28 292 application_postauthenticaterequest

2010-06-12 15:35:28 302 application_authorizerequest

2010-06-12 15:35:28 302 application_postauthorizerequest

2010-06-12 15:35:28 302 application_resolverequestcache

2010-06-12 15:35:28 312 application_postresolverequestcache

2010-06-12 15:35:28 312 application_postmaprequesthandler

2010-06-12 15:35:28 322 application_acquirerequeststate

2010-06-12 15:35:28 322 application_postacquirerequeststate

2010-06-12 15:35:28 322 application_prerequesthandlerexecute

2010-06-12 15:35:28 332 application_postrequesthandlerexecute

2010-06-12 15:35:28 332 application_releaserequeststate

2010-06-12 15:35:28 332 application_postreleaserequeststate

2010-06-12 15:35:28 342 application_updaterequestcache

2010-06-12 15:35:28 342 application_postupdaterequestcache

2010-06-12 15:35:28 342 application_endrequest

2010-06-12 15:35:28 342 application_presendrequestheaders

2010-06-12 15:35:28 342 application_presendrequestcontent

2010-06-12 15:36:40 034 session_end