欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

Asp.net的应用程序对象和页面生存周期

程序员文章站 2024-03-03 18:47:04
iis在接到一个新的http请求后,最终会调用asp.net_isapi.dll的 isapi扩展(特指iis6.0环境,iis7.0的应用程序池默认为集成方式,相对有所变...

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还提供了以下事件:

Asp.net的应用程序对象和页面生存周期

这些事件包括前面提到的可重载的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上下文一直伴随着各个环节向下传递
Asp.net的应用程序对象和页面生存周期

所以我们几乎可以在web应用中的任何环节,用httpcontext.current来引用到当前的上下文实例,从httpcontext的定义上,还可以发现context本身的属性中,又可以得到 application,applicationinstance,profile,response.request...等对象的实例引用

Asp.net的应用程序对象和页面生存周期

回想一下:

复制代码 代码如下:

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中定义了几个事件:

Asp.net的应用程序对象和页面生存周期

总体上讲:一个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类的定义下,可以看到

Asp.net的应用程序对象和页面生存周期

这似乎表明用户控件中,应该有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