The ASP.NET Page Life Cycle

When a page request is sent to the Web server, whether through a submission or location change, the page is run through a series of events during its creation and disposal. So let's examine in detail the eight events of an ASP.NET page, from creation to disposal. So these are the eight events that will be executed sequentially.

page_init
Loadviewstate
page_load
LoadPostData
RaisePostBackEvent
prerender
saveviewstate
Unload/Dispose


PAGE_INIT

The Page_Init event is the first to occur when an ASP.NET page is executed. This is where you should perform any initialization steps that you need to set up or create instances of server controls. You don't want to try to access controls in this event because there is no guarantee that they have been created yet. It is during this event that they are created, and you can control whether your attempt to use these objects will be thwarted by the server processing your request before the object has been created.Note that the Page_Init event fires only the first time the page is loaded. When you use a web form and post back to this page again, the Page_Init event doesn't fire. But the Page_Load event fires each time the page loads.

Load View state

After the Init event, controls can be referenced using their IDs only (no DOM is established yet for relative references). At LoadViewState event, the initialized controls receive their first properties: view state information that was persisted back to the server on the last submission. The page view state is managed by ASP.NET and is used to persist information over a page roundtrip to the server. View state information is saved as a string of name/value pairs and contains information such as control text or value. The view state is held in the value property of a hidden control that is passed from page request to page request. This event can be overridden using the LoadViewState method and is commonly used to customize the data received by the control at the time it is populated

PAGE_LOAD

This is the page event where you will be doing most of your work. This event occurs only when all the objects on the page have been created and are available for use.

Load Postback data

During this phase of the page creation, form data that was posted to the server (termed postback data in ASP.NET) is processed against each control that requires it. When a page submits a form, the framework will implement the IPostBackDataHandler interface on each control that submitted data. The page then fires the LoadPostData event and parses through the page to find each control that implements this interface and updates the control state with the correct postback data. ASP.NET updates the correct control by matching the control's unique ID with the name/value pair in the NameValueCollection. This is one reason that ASP.NET requires unique IDs for each control on any given page. Extra steps are taken by the framework to ensure each ID is unique in situations, such as several custom user controls existing on a single page. After the LoadPostData event triggers, the RaisePostDataChanged event is free to execute (see below).

Raise PostBack Change Events

As stated earlier, this occurs after all controls that implement the IPostBackDataHandler interface have been updated with the correct postback data. During this operation, each control is flagged with a Boolean on whether its data was actually changed or remains the same since the previous submit. ASP.NET then sweeps through the page looking for flags indicating that any object's data has been updated and fires RaisePostDataChanged. The RaisePostDataChanged event does not fire until all controls are updated and after the Load event has occurred. This ensures data in another control is not manually altered during the RaisePostDataChanged event before it is updated with postback data.

Prerender

The point at which the objects are prerendered is the last time changes to the objects can be saved or persisted to view state. This makes the PreRender step a good place to make final modifications, such as changing properties of controls or changing Control Tree structure, without having to worry about ASP.NET making changes to objects based off of database calls or view state updates. After the PreRender phase those changes to objects are locked in and can no longer be saved to the page view state. The PreRender step can be overridden using OnPreRender

ViewState Saved

The Viewstate is saved after all changes to the page objects have occurred. Object state data is persisted in the hidden object and this is also where object state data is prepared to be rendered to HTML. At the SaveViewState event, values can be saved to the ViewState object, but changes to page controls are not. You can override this step by using SaveViewState.

Page_Unload

Page_Unload is the counterpart to Page_Init. Just as Page_Init is an event that happens before anything else happens, Page_Unload happens after everything else happens. It is available for you to perform any operation you need to after you are completely finished with the page. For instance, imagine that you temporarily needed to create a file on the server during the page's processing. You wouldn't want to leave it there for eternity, especially if the file was unique to each visitor of the web site. You could have loads and loads of files building on your server without any way to get rid of them. But if you were a good boy or girl, you could destroy the file during the page's Page_Unload event and make the server administrator a happy camper.