ASP.NET 平台定義了兩個非常重要的生命周期。第一個是 應用生命周期 (application life cycle)，用來追蹤應用從啟動的那一刻到終止的那一刻。另一個就是 請求生命周期 (request life cycle)，它定義了 HTTP 請求在 ASP.NET 平台中首次接收到，到最終響應發出之間的路徑。
在 ASP.NET 中有兩個時刻——應用啟動的時刻和應用停止接收請求的時刻，這兩個時刻定義了應用生命周期。ASP.NET 在應用啟動和當應用在可控的情況下停止的時候提供了通知功能，我們接下來就讨論這樣的通知功能。
應用生命周期通知允許了我們在應用啟動或者應用在可控的情況下停止的時候執行某些任務。如果我們在應用啟動的時候需要執行一次性的配置任務或者在應用停止的時候需要釋放資源的時候，通知就會變得非常有用。MVC 架構開發者在應用生命周期中最常使用的就是配置一個依賴注入容器。MVC 架構使用應用生命周期來執行與請求相關的配置任務，比如建立 routes, areas, 和 content bundles。
ASP.NET 應用的生命周期從應用啟動的那一刻開始，在接收 HTTP 請求并處理生成響應的過程中一直延續。這包括将請求配置設定到合适的 controllers, actions 上，并從 Razor 視圖中渲染内容。生命周期直到應用停止的那一刻結束。
全局應用類在早期版本的 ASP.NET 中就已經存在了，它包含有兩個檔案：Global.asax 和 Global.asax.cs。嚴格來講，Global.asax 檔案才是全局應用類，而 Global.asax.cs 檔案是與之關聯的隐藏代碼 (code-behind) 檔案。這是一個很經典的 Web Forms 将聲明性代碼與程式設計性代碼分開的做法，但是現在，這僅僅是為了相容性，即使在 Web Forms 項目中。下面是 Global.asax 檔案中的内容，在 MVC 架構項目中，我們從不需要修改這個檔案。
之前版本中遺留下來的 Global.asax 檔案多少都會有點有趣，但是，我們關注的重點還是 Global.asax.cs 檔案。這個檔案的角色在 ASP.NET 進化的過程中也慢慢地改變了，現在 全局應用類 這個術語一般直接用來指 Global.asax.cs 檔案了，在解決方案資料總管中輕按兩下 Global.asax 檔案直接打開 Global.asax.cs 檔案你就可以明白其中緣由了。
下面是案例項目中 Global.asax.cs 檔案中的内容：
預設的全局應用類叫做 MvcApplication，繼承自 System.Web.HttpApplication 類。我們在後面會接觸到更多的 System.Web 命名空間下面的類。
MvcApplication 類由 ASP.NET 架構執行個體化，這裡面定義的方法會在應用生命周期的關鍵時刻被調用。
預設的 MvcApplication 類中隻包含了一個方法，叫做 Application_Start，但是還有另外一個方法可用，接下來我們就來介紹。
全局應用類支援兩種特殊的方法用來定義應用生命周期的開始與結束：
名稱
描述
Application_Start()
當應用啟動的時候調用
Application_End()
當應用将要終止的時候調用
Application_Start 方法在應用第一次啟動的時候被調用，并且提供了執行一次性配置任務的機會。比如，Visual Studio 在 Application_Start 方法中添加了建立 MVC areas 和 URL routes 的聲明。
Application_End方法僅會在應用終結之前執行，提供了釋放資源的機會。通常使用這個方法的理由就是釋放資料庫的連接配接，但是大多數的現代應用都不直接管理這樣的連接配接，我很少在自己的項目中使用到這個方法。而如今，資料庫已經能夠足夠好的管理它們的連接配接，而且，Application_End 方法僅會在應用在一個可控制的方式下關閉才會被調用到。是以我們不能夠依賴這個方法，因為伺服器可能發生不可預知的故障，比如突然斷電，這就會導緻 Application_End 方法并不會被執行。
我說這些方法是 特殊 的是因為它們實作的方式特别。這些方法并沒有定義在全局應用類的基類中 (System.Web.HttpApplication)，是以我們并不需要使用 override 關鍵字來實作它們。事實上，ASP.NET 架構使用反射的方式根據方法名稱來檢索它們。如果你寫錯了方法的名稱并不會得到任何的錯誤提示，ASP.NET 會假設你在應用開始或者結束的時候不想得到通知。正因為這樣，測試并確定你的代碼能夠被執行是非常重要的。
提示：有時候，我們在 Application_Start 和 Application_End 方法的定義中看到 Object 和 EventArgs 參數，這是為了遵循 C# 事件處理器方法的約定。這是可選的，ASP.NET 架構能夠定位到那些有這兩個參數或者沒有參數的方法。
圖 1 - 應用生命周期
我們可以在應用中直接使用 Application_Start 和 Application_End 方法來執行一次性的啟動和關閉任務。接下來，我将會教大家怎麼使用調試器來確定者兩個方法能夠被執行——特别是在我們自定義代碼不能夠像我們預期的那樣執行的時候顯得格外重要。
最簡單的方法來測試這些方法是否被執行就是使用 Visual Studio 的調試器，下面的代碼片段中，我們會看到怎麼在 Application_start 和 Application_End 方法中調用添加的靜态 System.Diagnostics.Debugger.Break 方法，這和我們在 Visual Studio 代碼編輯器中直接設定一個斷點的效果是一樣的。
測試 Application_Start 方法是非常簡單的，在 Visual Studio 調試菜單中選擇啟動調試，Visual Studio 會打開一個浏覽器視窗。ASP.NET 架構開始初始化這個應用，建立了一個全局應用類的執行個體，發現了 Application_Start 方法，然後調用它，這将會引起 Break 方法被調用。應用的執行将會暫停，控制将會傳遞給調試器，如下圖所示：
在調試菜單中選擇繼續，應用的執行将會恢複。來自浏覽器的請求将會被處理，并生成相應的 HTML 響應發送給使用者。
測試 Application_End 方法有一點點困難，因為如果選擇停止調試将會導緻在 Application_End 方法被調用之前調試器将會從應用上分離出去。浏覽器視窗關閉，調試器終止掉，Visual Studio 将會傳回到預設的狀态——然而，Debugger.Break 方法并沒有被調用。
為了測試 Application_End 中的代碼，我們必須直接使用 IIS Express，而非通過 Visual Studio。IIS Express 是 Visual Studio 中自帶的一個簡化版的 IIS 應用伺服器，隻是用于在開發過程中運作 ASP.NET 應用的。
在 Windows 工作列中定位到 IIS Express 圖示，右擊它會有一個彈窗菜單出現。在菜單項目中，我們會看到一個 SimpleApp 項目（應用名稱），當你選中它的時候會看到一個停止站點菜單項目，如下圖所示：
圖 3 - 使用 IIS Express 停止一個應用
當選擇停止站點的時候，IIS Express 會停止這個應用，作為處理過程的一部分，Application_End方法将會被調用。在本例中，Debugger.Break 方法将會被調用，如下圖所示：
圖 4 - 測試 Application_End 方法中的代碼
[根據 Adam Freeman – Pro ASP.NET MVC 5 Platform 選譯]