To fully understand how data controls work, it’s important to know how they fit into the page life cycle. This is imporant when you run into a situation where you need to work with or extend the data binding model. Take, for instance, a situation where you might want to add data or set a selected item in a control after it has been bound to the data source. Depending on the circumstances, you might be able to respond to data source control events, but they aren’t always fired at the point you need to perform your programming logic.The data binding takes place in this order:
- The page object is created (based upon the .aspx file)
- The page life cycle begins and the Page.Init and Page.Load events fire.
- Any other control events fire.
- The data source controls perform any necessary updates. If a row has been updated, then the Updating and Updated events will fire. If a row has been inserted, then the Inserting and Inserted events will fire. If a row as been deleted, then the Deleting and Deleted events will fire.
- The Page.PreRender event fires.
- The data source controls perform their queries and insert the retrieved data in the linked controls. Then, the Selecting and Selected events will fire at this point.
- Finally, the page is rendered and disposed.
You need to understand that this process is repeated for each and every request. That means that the data source controls query the database every time the page is posted back. This may sound like unnecessary work for your database. Well, guess what? It is. The proper solution would be to use caching so that the data you retrieve is kept in memory and then reused. This bypasses the database on subsequent requests.
In future posts, I’ll show you how this is done.