views:

39

answers:

1

In all my Page_Load() events I have to do a

if(!IsPostBack)
{
  //code runs on initial get
  //Set properties backed by viewstate
}
else
{
  //Code runs on each get and post
  //Set properties backed by ordinary fields
}

Is there any quick way to determine this short of reflector, reading documentation, or creating a test page?

Is it better to adopt a convention that viewstate doesn't really exist, because you don't know if it does without researching it on all of the potentially 1000s of properties you might need to set in a large line of business application?

+1  A: 

This seems to be more of a design question - When to use ViewState. Since you have the source you obviously know which controls uses ViewState, so no guesswork or discovery is needed.

IsPostback is the usual way to determine GET or POST. You can also examine Request.HttpMethod. For deciding when to use ViewState, will the page Postback before the completion of its task (i.e update some controls based on user actions)? If you will Postbck, and the cost of populating all the fields is too high, then use ViewState. Or use Ajax calls to avoid Postbacks for just updating content.

Remember when you do Postback you don't need ViewState to read the values. The controls are passed in the Form collection.

ka3751
Hmm, I didn't choose to use viewstate all the 3rd party controls I use may or may have not, but that gives me an idea to try to create a method to iterate over the controls ViewState collection to see what is there.
MatthewMartin