来一篇关于NET的HttpApplication,HttpModule,HttpContext及Asp.Net页性命周期
实不相瞒，Java是我见过的执行效率最低的程序设计语言，前不久在CSDN论坛上有个评测，计算9999的阶乘，同样的循环算法，Java的耗时是.NET的5倍。IIS在接到一个新的http哀求后，终极会挪用asp.net_isapi.dll的ISAPI扩大(特指IIS6.0情况，iis7.0的使用程序池默许为集成体例，绝对有所变更)，然后传送到httpRuntimePipe(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的)
publicclassGlobal:System.Web.HttpApplication再来看一下绝对asp而言，新增的Context,Modules,User这三个属性
Context：
Context即HttpContext类的实例，在几近全部aspx页面熟命周期中，Context高低文一向陪伴着各个环节向下传送
以是我们几近能够在web使用中的任何环节，用HttpContext.Current来援用到以后的高低文实例，从HttpContext的界说上，还能够发明Context自己的属性中，又能够失掉Application,ApplicationInstance,Profile,Response.Request...等工具的实例援用
回忆一下：
publicclassHandler1:IHttpHandler{publicvoidProcessRequest(HttpContextcontext){context.Response.ContentType="text/plain";context.Response.Write("HelloWorld");}publicboolIsReusable{get{returnfalse;}}}我们在利用一个ashx文件时，ProcessRequest办法即是把以后高低文传送出去，进而经由过程context失掉Response工具的援用，终极能够向页面输入任何想要的内容.
Modules:
每个完成了IHttpModule接口的类，就能够被以为是Http模块组件，能够了解为http哀求拦阻器，拦阻到http哀求后，它能修正正在被处置的Context高低文，完事儿以后，再把把持权交还给管道，假如另有别的模块，则顺次持续处置，直到一切Modules汇合中的HttpModule都“爽”完为止(注：不幸的http哀求就如许给各个httpModule轮X了)
asp.net2.0默许内置了良多HttpModule，从Machine.Config文件中能够发明以下默许的内置模块:
注2
AnonymouseIdentification--为匿名用户分派一个一时身份
FileAuthorization--考证用户是不是有哀求文件的WindowsNT允许
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后被触发.
<P>最初再把HttpApplication的事务思索出去，看下叠加后的按次，不外先别发急，我们先来看一种特别情形，假如一个asp.net使用根目次下未设置默许页，这时候间接扫瞄根目次，好比http://localhost:2345/时，Globl.ascx.cs中界说的Application_XXX办法的挪用按次以下：
2010-03-2815:01:39413Application_Start
2010-03-2815:01:39491Init
2010-03-2815:01:39491Application_BeginRequest
2010-03-2815:01:39506Application_AuthenticateRequest
2010-03-2815:01:39506Application_PostAuthenticateRequest
2010-03-2815:01:39506Application_AuthorizeRequest
2010-03-2815:01:39522Application_PostAuthorizeRequest
2010-03-2815:01:39522Application_ResolveRequestCache
2010-03-2815:01:39522Application_PostResolveRequestCache
2010-03-2815:01:39522Application_PostMapRequestHandler
2010-03-2815:01:39522Application_AcquireRequestState
2010-03-2815:01:39537Application_PostAcquireRequestState
2010-03-2815:01:39537Application_PreRequestHandlerExecute
2010-03-2815:01:39553Application_Error
2010-03-2815:01:39553Application_EndRequest
2010-03-2815:01:39569Application_PreSendRequestHeaders
2010-03-2815:01:39569Application_PreSendRequestContent
能够看到会触发Application_Error事务，即HttpRuntime以为这是一个毛病.
紧接着再扫瞄一个实践存在的页面，假如这时候使用程序有严峻毛病，招致Application封闭(好比web.config设置毛病)，挪用的按次以下:
2010-03-2815:03:47704Application_BeginRequest
2010-03-2815:03:47704Application_AuthenticateRequest
2010-03-2815:03:47766Application_PostAuthenticateRequest
2010-03-2815:03:47766Application_AuthorizeRequest
2010-03-2815:03:47766Application_PostAuthorizeRequest
2010-03-2815:03:47766Application_ResolveRequestCache
2010-03-2815:03:47783Application_PostResolveRequestCache
2010-03-2815:03:48667Application_PostMapRequestHandler
2010-03-2815:03:48667Application_AcquireRequestState
2010-03-2815:03:48683Application_PostAcquireRequestState
2010-03-2815:03:48698Application_PreRequestHandlerExecute
2010-03-2815:03:48745Page_PreInit
2010-03-2815:04:02903Page_Unload
2010-03-2815:04:02903Application_Error
2010-03-2815:04:02918Application_EndRequest
2010-03-2815:04:02996Application_PreSendRequestHeaders
2010-03-2815:04:02996Application_PreSendRequestContent
2010-03-2815:04:03371Application_Disposed
2010-03-2815:04:03371Dispose
2010-03-2815:04:03386Application_End
对照方才的按次，会发明Application_Start及Init没有再次被挪用，也印证了文章后面提到的一些结论(Application_Start在全部asp.net使用性命周期内只触发一次)，并且从最初的三个输入能晓得：使用程序封闭时Application_Disposed,Dispose,Application_End按按次挪用.
再"从头"扫瞄(指webServer重启)一下一般会见的页面，在不堕落也不回发的情形下，按次以下:
2010-03-2815:08:11513Application_Start
2010-03-2815:08:11591Init
2010-03-2815:08:11591Application_BeginRequest
2010-03-2815:08:11591Application_AuthenticateRequest
2010-03-2815:08:11591Application_PostAuthenticateRequest
2010-03-2815:08:11606Application_AuthorizeRequest
2010-03-2815:08:11606Application_PostAuthorizeRequest
2010-03-2815:08:11606Application_ResolveRequestCache
2010-03-2815:08:11606Application_PostResolveRequestCache
2010-03-2815:08:11622Application_PostMapRequestHandler
2010-03-2815:08:11637Application_EndRequest
2010-03-2815:08:11637Application_PreSendRequestHeaders
2010-03-2815:08:11637Application_PreSendRequestContent
2010-03-2815:08:11637Application_BeginRequest
2010-03-2815:08:11637Application_AuthenticateRequest
2010-03-2815:08:11653Application_PostAuthenticateRequest
2010-03-2815:08:11653Application_AuthorizeRequest
2010-03-2815:08:11653Application_PostAuthorizeRequest
2010-03-2815:08:11653Application_ResolveRequestCache
2010-03-2815:08:11653Application_PostResolveRequestCache
2010-03-2815:08:11653Application_PostMapRequestHandler
2010-03-2815:08:11653Session_Start
2010-03-2815:08:11653Application_AcquireRequestState
2010-03-2815:08:11653Application_PostAcquireRequestState
2010-03-2815:08:11653Application_PreRequestHandlerExecute
2010-03-2815:08:11669Page_PreInit
2010-03-2815:08:11684Page_Init
2010-03-2815:08:11684Page_InitComplete
2010-03-2815:08:11684Page_PreLoad
2010-03-2815:08:11684Page_Load
2010-03-2815:08:11684Page_LoadComplete
2010-03-2815:08:11684Page_PreRender
2010-03-2815:08:11684Page_SaveStateComplete
2010-03-2815:08:11700Page_Unload
2010-03-2815:08:11700Application_PostRequestHandlerExecute
2010-03-2815:08:11700Application_ReleaseRequestState
2010-03-2815:08:11700Application_PostReleaseRequestState
2010-03-2815:08:11700Application_UpdateRequestCache
2010-03-2815:08:11700Application_PostUpdateRequestCache
2010-03-2815:08:11700Application_EndRequest
2010-03-2815:08:11700Application_PreSendRequestHeaders
2010-03-2815:08:11700Application_PreSendRequestContent
2010-03-2815:08:11793Application_BeginRequest
2010-03-2815:08:11793Application_AuthenticateRequest
2010-03-2815:08:11793Application_PostAuthenticateRequest
2010-03-2815:08:11793Application_AuthorizeRequest
2010-03-2815:08:11793Application_PostAuthorizeRequest
2010-03-2815:08:11793Application_ResolveRequestCache
2010-03-2815:08:11793Application_PostResolveRequestCache
2010-03-2815:08:11809Application_PostMapRequestHandler
2010-03-2815:08:11809Application_AcquireRequestState
2010-03-2815:08:11809Application_PostAcquireRequestState
2010-03-2815:08:11809Application_PreRequestHandlerExecute
2010-03-2815:08:11825Application_PostRequestHandlerExecute
2010-03-2815:08:11825Application_ReleaseRequestState
2010-03-2815:08:11840Application_PostReleaseRequestState
2010-03-2815:08:11949Application_UpdateRequestCache
2010-03-2815:08:11949Application_PostUpdateRequestCache
2010-03-2815:08:11965Application_EndRequest
2010-03-2815:08:11981Application_PreSendRequestHeaders
2010-03-2815:08:11981Application_PreSendRequestContent
哇！本来一个页面会见上去，会挪用到这么多的办法，怪不得良多高并发的年夜型网站，一般都要本人写一个精减的HttpHandler用来代替Page做为基类，以希冀取得更好的功能
最初：我们在做网站开辟时，不成能只用到Page页，良多时分还会用到UserControl（用户自界说控件），先看下它的承继干系，好比我们创立了一个TestUserControl的用户控件
TestUserControl-->UserControl--->TemplateControl-->Control
终极在Control类的界说下，能够看到
这仿佛标明用户控件中，应当有Page_Init,Page_Load,Page_Unload...等事务，一般我们只用到Init,Load事务，假如到场一个用户控件后，全部性命周期就更庞大了：
2010-06-1215:35:28042Application_Start
2010-06-1215:35:28072Init
2010-06-1215:35:28072Application_BeginRequest
2010-06-1215:35:28082Application_AuthenticateRequest
2010-06-1215:35:28082Application_PostAuthenticateRequest
2010-06-1215:35:28092Application_AuthorizeRequest
2010-06-1215:35:28102Application_PostAuthorizeRequest
2010-06-1215:35:28102Application_ResolveRequestCache
2010-06-1215:35:28112Application_PostResolveRequestCache
2010-06-1215:35:28122Application_PostMapRequestHandler
2010-06-1215:35:28142Application_EndRequest
2010-06-1215:35:28142Application_PreSendRequestHeaders
2010-06-1215:35:28142Application_PreSendRequestContent
2010-06-1215:35:28152Application_BeginRequest
2010-06-1215:35:28152Application_AuthenticateRequest
2010-06-1215:35:28162Application_PostAuthenticateRequest
2010-06-1215:35:28162Application_AuthorizeRequest
2010-06-1215:35:28162Application_PostAuthorizeRequest
2010-06-1215:35:28172Application_ResolveRequestCache
2010-06-1215:35:28172Application_PostResolveRequestCache
2010-06-1215:35:28172Application_PostMapRequestHandler
2010-06-1215:35:28172Session_Start
2010-06-1215:35:28172Application_AcquireRequestState
2010-06-1215:35:28182Application_PostAcquireRequestState
2010-06-1215:35:28182Application_PreRequestHandlerExecute
2010-06-1215:35:28192Page_PreInit
2010-06-1215:35:28192TestUserControl.Page_Init
2010-06-1215:35:28202Page_Init
2010-06-1215:35:28202TestUserControl.TestProperty.Set
2010-06-1215:35:28202Page_InitComplete
2010-06-1215:35:28202Page_PreLoad
2010-06-1215:35:28202Page_Load
2010-06-1215:35:28202TestUserControl.Page_Load
2010-06-1215:35:28202TestUserControl.ShowData()
2010-06-1215:35:28212TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28212TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28212TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28212TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28212TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28222TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28222TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28222TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28222TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28222TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28232TestUserControl.Repeater1.ItemDataBound()
2010-06-1215:35:28232Page_LoadComplete
2010-06-1215:35:28232Page_PreRender
2010-06-1215:35:28232TestUserControl.Page_PreRender
2010-06-1215:35:28242Page_SaveStateComplete
2010-06-1215:35:28242TestUserControl.Page_Unload
2010-06-1215:35:28252Page_Unload
2010-06-1215:35:28252Application_PostRequestHandlerExecute
2010-06-1215:35:28252Application_ReleaseRequestState
2010-06-1215:35:28252Application_PostReleaseRequestState
2010-06-1215:35:28262Application_UpdateRequestCache
2010-06-1215:35:28262Application_PostUpdateRequestCache
2010-06-1215:35:28262Application_EndRequest
2010-06-1215:35:28272Application_PreSendRequestHeaders
2010-06-1215:35:28272Application_PreSendRequestContent
2010-06-1215:35:28282Application_BeginRequest
2010-06-1215:35:28292Application_AuthenticateRequest
2010-06-1215:35:28292Application_PostAuthenticateRequest
2010-06-1215:35:28302Application_AuthorizeRequest
2010-06-1215:35:28302Application_PostAuthorizeRequest
2010-06-1215:35:28302Application_ResolveRequestCache
2010-06-1215:35:28312Application_PostResolveRequestCache
2010-06-1215:35:28312Application_PostMapRequestHandler
2010-06-1215:35:28322Application_AcquireRequestState
2010-06-1215:35:28322Application_PostAcquireRequestState
2010-06-1215:35:28322Application_PreRequestHandlerExecute
2010-06-1215:35:28332Application_PostRequestHandlerExecute
2010-06-1215:35:28332Application_ReleaseRequestState
2010-06-1215:35:28332Application_PostReleaseRequestState
2010-06-1215:35:28342Application_UpdateRequestCache
2010-06-1215:35:28342Application_PostUpdateRequestCache
2010-06-1215:35:28342Application_EndRequest
2010-06-1215:35:28342Application_PreSendRequestHeaders
2010-06-1215:35:28342Application_PreSendRequestContent
2010-06-1215:36:40034Session_End捆绑编译器。用户不需要受制于厂家，自己就能将程序在新平台上编译运行。除了牛B轰轰的linux，估计也没有系统捆绑c/c++的编译器，而且许多新平台都无法支持复杂的c/c++编译器在上面直接运行。 ASP.net的服务器，要求安装一个.net环境，当然我这里指的是windows系统，顺便点一下，.net只能放在windows环境里来运行。Asp.net1.1的就装Framework1.1，Asp.net2.0的就装Framework2.0。 但是目前在CGI中使用的最为广泛的是Perl语言。所以，狭义上所指的CGI程序一般都是指Perl程序，一般CGI程序的后缀都是.pl或者.cgi。 是目前ASP在UNIX/Linux上的应用可以说几乎为0）。所以平台的局限性和ASP自身的安全性限制了ASP的广泛应用。 市场决定一切，我个人从经历上觉得两者至少在很长时间内还是要共存下去，包括C和C++，至少从找工作就看得出来，总不可能大家都像所谓的时尚一样，追捧一门语言并应用它。 ASP在执行的时候，是由IIS调用程序引擎，解释执行嵌在HTML中的ASP代码，最终将结果和原来的HTML一同送往客户端。 主流网站开发语言之CGI:CGI就是公共网关接口(CommonGatewayInterface)的缩写。它是最早被用来建立动态网站的后台技术。这种技术可以使用各种语言来编写后台程序，例如C，C++，Java，Pascal等。 通过这次激烈的讨论，我从大家身上学到了太多，开阔了眼界，不管是支持我的还是骂我的，都感谢你们。 通过这次激烈的讨论，我从大家身上学到了太多，开阔了眼界，不管是支持我的还是骂我的，都感谢你们。
页:
[1]