Understanding the ASP.NET Page Life Cycle

We’ve seen that ultimately a Web request for an .aspx page handled by ASP.NET goes to an object that implements the IHttpHandlerFactory interface. The pipeline created by ASP.NET to process the request includes a set of IHttpModule objects that can participate in certain events. The ASP.NET IHttpHandlerFactory object ultimately delegates execution to a Page class. The Page classes created by ASP.NET are the result of generating IHttpHandler objects from the .aspx page itself, which can be a mix of declarative server controls as well as user code.

The page execution has a set of events that can be leveraged by user code in the page itself or from within code in user controls (which will be discussed in more detail in Chapter 2). Much of the page developer’s code utilizes the set of page life-cycle events. We’ll be using them in examples throughout the book, beginning here. There are additional virtual page methods for which the developer can provide overrides. What is different about these events is that by providing user code with the well-known name, the event binding is performed automatically by ASP.NET, which further simplifies the mainstream scenario of developers utilizing these events.

Page_Init

The Page_Init method corresponds to the Init event and occurs very early in the life cycle. ASP.NET utilizes this event for, among other things, processing posted form data to restore controls to the state they were in on the previous request. In Code Listing 1-6, PageEvents.aspx demonstrates using this well- known method to write directly to the output.

This event occurs early enough in the page life cycle that it is too early for much of the Web application code you will be writing. Application functional code is better placed in the Page_Load method, after state has been restored.

Page_Load

Much of the Web application developer’s code is placed in the Page_Load method. At this point, the control tree is created and the properties have been restored to any values previously stored in viewstate. Again, in Code Listing 1-6 is code for this method, which simply writes to the output stream, allowing us to see when the events occur.

Code Listing 1-6: PageEvents.aspx

 <script language="C#" runat="server">
protected void Page_Init(object o, EventArgs e) {
    Response.Write("Page_Init method called <br/>");
}
 
protected void Page_Load(object o, EventArgs e) {
    Response.Write("Page_Load method called <br/>");
}
 
protected void Page_Unload(object o, EventArgs e) {
    //cannot use the Response object here, the page is unloading
    //Response.Write("Page_Unload method called <br/>");
}
</script>
<form runat="server">
    <asp:label runat="server" Text="output from label server control"/><br/>
</form> 

Page_Unload

After the page has executed and all other page and control events have been raised, the Unload event is called. The Page_Unload method is ideal for closing any temporary connections or calling Dispose on objects that would otherwise keep valuable operating system resources held until garbage collection.

When you view the output from the PageEvents.aspx in Figure 1-3, notice that the order of events is as you would probably expect: first is the output from the Page_Init method, followed by that of the Page_Load method. Next comes the output from the controls on the page. Although we have a call to Response.Write in the Page_Unload method, it is commented out. At the point that the Unload event occurs, the HttpContxt no longer provides us with the ability to write to the output stream.

Figure 1-3: Page events output