views:

297

answers:

3

Hello all,

A question I have been thinking about for a while - would Stackoverflow users commonly implement significant functionality in a constructor (specifically in classes derived from the System.Web.UI.Page class) , or should we keep the logic here as simple as possible and instead implement functionality in OnPreInit (using the constructor to simply instantiate objects/values that are required for the functionality in the rest of the page to function)? Is there a "best-practice" approach to this scenario?

The background to this question:

The system that I am working on has a fairly deep page hierarchy - there are about 10 chained page objects that the actual page derives from:


-- System.Web.UI.Page 
----- CustomPage1 : System.Web.UI.Page 
-------- CustomPage2 : CustomPage1
---------- etc

Each page adds a specific piece of functionality, and often there is either a dependancy on code run within the custom page constructor, or the functionality itself is directly run during construction.

The example that best illustrates my question is the page that loads custom objects from our database to the page so they are available during the page lifecycle - during page construction connections are made to the database and then public properties are populated with the correct values.

To my mind this is better done from the OnPreInit event, mainly because we have greater flexibility to perform some page level checks (e.g. should we want to prevent this functionality being called) before the parent logic is run (given that in a constructor the order of execution will construct the parent classes before the child class). From an OO perspective as well OnPreInit seems to be a more appropriate area to implement this functionality - page construction should deal with construction of the page, setting any default values, etc and then OnPreInit would be used to perform any functionality that was required during the lifecycle of the page.

+1  A: 

I think your reasoning is very sound - I agree that OnPreInit is the proper place for such logic.

Andrew Hare
+1  A: 

Depending on the actual functionality I would suggest using OnInit or OnLoad or even instead of OnPreInit. OnPreInit was introduced to support setting the theme or master page dynamically, what you cannot do later in the lifecycle.

csgero
Interesting about OnPreInit, I did not know that history. I think I may need to hijack that tho, I need to run functionality before the other pages get to OnInit :(
Chris
A: 

Keep in mind that control values have not been restored from ViewState OnPreInit if it's a postback.

MSDN gives suggestions for event use. See "Life-Cycle Events". Examples:

  • PreInit - Create or re-create dynamic controls
  • Init - Use this event to read or initialize control properties.
  • Load - Use the OnLoad event method to set properties in controls and establish database connections.
Corbin March
Yeah, the Viewstate should be fine - the system is only using session variables to determine the data to load.
Chris