Life Cycle in ASP.NET
When a web page is sent to the Web Server for processing, it goes through a sequence of steps before it finally gets displayed in the Web Browser. This article discusses these series of steps and events that occur in a page life cycle in ASP.NET.
From Web Browser to IIS
When a POST request is initiated from the client side, the Web Server traps the request and it is usually routed to an .aspx web page. The request is actually routed to the HTTP Pipeline, a chain of managed objects.
After the HTTP Page handler class is identified, the ProcessRequest () method is called which eventually fires the different page events in the life cycle of a web page. The sequence of events that takes place in the life cycle of a web page in ASP.NET is:
- Page_Init
- LoadViewState
- LoadPostData
- Page_Load
- RaisePostDataChangedEvent
- RaisePostBackEvent
- Page_PreRender
- SaveViewState
- Page_Render
- Page_UnLoad
All these events are associated with their respective handlers and you can even override them to customize their default behaviour. The following section discusses each of these events in detail.
The Page Life Cycle Events Explained
Once the request for the web page arrives at the web server, the ASP.NET runtime determines whether the page needs to be parsed or whether a cached version of the page needs to be rendered to the requestor. Then the Request and the Response objects for the page are set and the page life cycle starts.
The Page_Init event is the first event to be triggered in the page life cycle. It is responsible for the initialization activities that are essential to create a page instance. In this phase of the page life cycle, all the server controls of the web page are initialized to their default values. However, it should be noted that the View State for a page is not available at this stage of the page life cycle and a server control of the page cannot access other server controls of the page at this phase.
You can use the Page_Init event to create or re-create the controls that need to be created or re-created dynamically. The following example illustrates how you can override the OnInit() method.
protected override void OnInit(EventArgs e)
{
if (Page != null)
{
Page.Trace.Write ("The OnInit method has been called");
base.OnInit(e);
Page.RegisterRequiresPostBack(this);
}
}
Next, the LoadViewState method is called. "The load view state stage only happens when the page has been posted back. During this stage the view state data saved from the previous page visit is loaded and recursively populated into the Page’s control hierarchy". This method restores the View State information of a web page that was last saved using the SaveViewState method. You can override the LoadViewState() method to get an idea on how the viewstate is actually restored.
The following code example illustrates how you can override the LoadViewState() method.
protected override void LoadViewState(Object viewState)
{
Page.Trace.Write ("The LoadViewState method has been called.");
if (viewState == null)
{
base.LoadViewState(viewState);
}
}
View State is a hidden field that is associated with every web page. It is responsible for maintaining the state of web pages between postbacks. It maintains a state of a page as it moves back and forth between the web browser at the client side and the web server at the server side. However, it should be noted that ViewState does not hold the controls, rather it holds the values of the form controls and their corresponding ID's that would otherwise be lost due to a post back because they do not post with the form.
After the View State for a web page is restored, the server controls in the web page are populated with posted data, i.e., the data that was posted when the web page was sent from the we browser at the client side to the web server.
The LoadPostBackData event is fired next that processes the data that was last posted to the server for all the server controls that requires the same. Note that all controls in an ASP.NET web page is identified by a unique id. The runtime now parses the controls to match their unique ids against the Name Value Collection in the View State for the control (that has its View State enabled) and updates the control with the posted data.
The next event that gets fired is the Page_Load event that typically restores the page's control values. At this phase of the page life cycle, the web page "calls the OnLoad event method on the Page, then recursively does the same for each child control, which does the same for each of its child controls until the page and all controls are loaded." Typically, you bind data to the controls of your web form in this method or call methods write code that should be executed or loaded first before any other event of the web page is triggered.
A typical example of Page_Load event is cited below.
protected override void OnLoad(EventArgs e)
{
if(!IsPostBack)
{
//Code to bind static data to the controls
}
}
You can check the IsPostBack property of the web page to avoid re-setting the server control values. But why is the IsPostBack property necessary? Well, the reason is that the Page_Load event is fired with every request to the web page. Hence, this property is used to check whether the page was submitted to itself. Further, you can create dynamic controls for your web page here.
