Designing ASP.NET websites is easier if you understand the Life Cycle of the ASP.NET controls. Let's review the ASP.NET controls (Refer to table 1). These include:

• Page (Master Page)
  
• User Control
  
• Web Control
  
• Html Control
  
• Composite Control
  
• Web Part
  

From an object model perspective, the Life Cycle methods are derived from Control, Web Control and Composite Control.

The table presents ASP.NET controls mapped against Life Cycle methods. This is what I think of as the 'get started' Life Cycle for controls. There are more Life Cycle methods, e.g. Pre-Init, if you want to manage Master Pages and Themes for a page. Here are some observations:

• You don't need to use all of the states when writing a control
  
• You are best served if you match functionality to the correct Life Cycle method
  
  • Your control will behave properly in all use cases.
    
  • Subtle bugs can occur because you have placed functionality in a non-optimal Life Cycle method
    

Table 1: Life Cycles of various ASP.NET Controls

Controls and the Life Cycle

Html Controls are simple controls that inherit from Control. As such, valid Life Cycle methods include:

• Init
  
• Load Control State
  
• Load
  
• Post back event handling
  
• Pre Render
  
• Save Control State
  
• Dispose
  
• Unload
  

Page, User Control and Web Control includes the methods above, plus:

• Load View State
  
• Save View State
  
• Render
  

The Composite Control and Web Part include the base methods from above, plus:

• Create Child Controls
  

Composite Controls

Being a Web Part designer means that I use Composite Controls. Composite Controls are different in that they have a Life Cycle method called 'CreateChildControls'. (This is probably because of the history of Web Parts and SharePoint.) Here are a couple of notes from MSDN documentation on Composite Controls.

The CompositeControl class is new in ASP.NET 2.0. If you created custom controls in ASP.NET version 1.0 or 1.1, you had to implement the INamingContainer interface to create a new naming scope for child controls. In addition, you had to override the Controls property and invoke the EnsureChildControls method. In ASP.NET 2.0, these and other steps are performed by the CompositeControl class.

You should create the child controls in the CreateChildControls method and not in OnInit or another life cycle phase. The server control architecture relies on calls to CreateChildControls whenever the Controls collection is needed, such as during data binding (if applicable).

Note 1: When the Composite Control is displayed normally, 'CreateChildControls' is called AFTER the 'Load' method. However, when a post back event occurs, 'CreateChildControls' is called AFTER the 'Init' method. This certainly makes the 'CreateChildControls' method an "interesting" aspect of the Life Cycle.

References

• http://blogs.thesitedoctor.co.uk/tim/2006/06/30/Complete+Lifecycle+Of+An+ASPNet+Page+And+Controls.aspx – this shows a trace of the Life Cycles of MasterPage, Page, and various Controls.
  
• http://msdn.microsoft.com/en-us/library/ms178472.aspx - this describes the Page Life Cycle.