The viewstate stores a serialized copy of state information for your controls. For example, if you databind a grid, the grid can store all of the data to which it is bound in the ViewState so you don't have to re-populate the grid on the next post back (in theory, this alleviates having to re-hit the database for the data).
This can be both a blessing a curse because if your grid is huge, then your ViewState is likely also very large. And the problem with the view state is that it goes down to the browser, then from the browser back to the server, so it's a double-hit. If you are on an internal network, this may not be a big deal because that information goes really fast. If you are on a dial-up connection then it's going to suck big time. A lot of people are on broadband connections, and they sit somwhere in the middle. The page may be a bit sluggish, but it's not ridiculous.
I tend to use the viewstate only for small pieces of data. For data displayed in grids, I turn viewstate off, cache the data, and rebind on every request. This alleviates multiple database hits and keeps the viewstate to a minimum. If caching isn't an option, then I just bit the bullet and hit the database again but attempt to keep the infomation comming back to a minimum (e.g. paging the records).
You do have to be careful, however, because some controls will not fire their events if they are not bound when the control initializes. When the viewstate is on, Events will fire correctly because the serialized information is populated into the control. If you turn the viewstate off, you have to manually bind in the initialization so the events fire correctly.
Damon Armstrong, Technology Consultant
[
Blog] [
Articles]