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

view sourceprint?

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

view sourceprint?

/// <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

view sourceprint?

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頁面生命周期的權威解釋

文中源碼

總結

以上是生活随笔為你收集整理的温故而知新：HttpApplication,HttpModule,HttpContext及Asp.Net页生命周期的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。