网站建设哪个品牌好,网站建设发朋友圈的图片,网站推广120,十大电子游戏平台网站IIS在接到一个新的http请求后#xff0c;最终会调用asp.net_isapi.dll的ISAPI扩展(特指IIS6.0环境#xff0c;iis7.0的应用程序池默认为集成方式#xff0c;相对有所变化)#xff0c;然后传递到httpRuntime Pipe(http运行时管道)#xff0c;Asp.Net这时才开始运行(即HttpR…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文件中可以发现以下默认的内置模块: 注2AnonymouseIdentification --为匿名用户分配一个临时身份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页面生命周期的权威解释 文中源码 留下QQ号码或加QQ:691647004 一起讨论转载于:https://www.cnblogs.com/boyjsj/archive/2011/05/05/abouthttp.html
