A Practical Tutorial for the ASP.Net Event Model

There are likely a million guides on the web that detail the asp.net event model; however, many developers still do not grasp how to use the events properly. If you want a detailed guide to the events, try this resource. The goal of this post is to provide a guide to the actual use of the most important events; not to provide exhaustive details on everything. Also keep in mind the suggestions in this post apply most of the time; but as always, decisions have to be made on a case by case basis as your specific page may have circumstances that make it very different.

1. Page_Init

• Populate lists, such as drop-downs


• Set default/initial values for inputs


• Inject content into literals

As the name implies, this event should be used for initialization of your controls. Setting default values here has several advantages. First, even if you forget to check whether the current request is a postback, your initializations will not overwrite values set by the users. Second, you get a performance boost because you do not clog up the view state. Many sources suggest using the view state to reduce database requests thereby increasing performance; however, I disagree as this is actually the duty of data-caching. One caveat to remember about Page_Init is that it cannot be used to initialize controls or populate lists when the initialization value is dependent on the value of another control. Resist the urge to set control visibility in Page_Init; it might seem to make sense at first, but will cause you trouble later.

2. Page_Load

• Initialize controls (which might not have been visible prior to the postback) when their values are dependent on the values of other controls in the page

Page_Load is by far the least useful event on this list despite the fact that it is the event most commonly used by many developers. I cannot think of a good reason to put anything in Page_Load unless it is only used in a post back to vary page content based on user input. Resist the urge to put pretty much anything in this event. Above all else, avoid databinding in the Page_Load or you will regret it later!

3. Control Events

• Save content changes to the database


• Set flags on instance fields


• Custom validation


• Possibly redirects (try to avoid using POST requests to do redirects as it makes your site harder to use)

The control events are where data storage should be done whether it's to the database or some other medium; don't forget to check whether your page is valid. Control events are also a great place to execute business logic. Resist the urge to make UI changes in the control events (such as setting control visibility); instead set a flag and make the change in Page_PreRender. Some obvious exceptions to this rule are events like calendar DayRender or repeater DataBinding.

4. Page_PreRender

• Set whether the control is visible


• Set whether the control is enabled


• Changes in content based on a varying mode or stage


• Data-Binding!

First and foremost, this is where databinding should be triggered. This is because Page_PreRender is when your data will be in the state that you want the user to see. Prematurely triggering a databind can give users the impression that their changes did not go through. Page_PreRender is also where Visible and Enabled properties of controls should be set. Taking these steps here ensures your user gets the proper content if you're varying a page based on stage or mode in your business logic. Resist the urge to do resource cleanup in this event; that should be done in Page_Unload. If you are the type of developer that hates maintainable code and used a markup datasource, databinding can occur after the Page_PreRender event making resource clean up inappropriate here.