On page 292 of your book you state:
"Removing the check for Page.IsPostback is enough to accomplish this. However this is not always the desired solution. Imagine that you are getting correct display direction from a database. Because the number of times that you hit a database can be a costly operation, you want to minimize the number of times that you hit the database."

My question to you would be is not Viewstate a pricely and cumbersome overhead to the overall footprint of the application as well? Can Viewstate not also have a tendency to gum up the works so to speak on any .NET application?

Thank you for your attention to this matter.

I guess maybe I should clarify my question just a bit more. The real question becomes what factors do you use to balance using viewstate as opposed to hitting the database? Are there any hard and fast rules in .NET for any of this when making these considerations?

No. You need to outweigh the pros and cons. If it's not directly clear, you'll need to measure performance and network trafic.

A complex number that takes 1 minute to calculate but only takes up the size of an integer is a good candidate to store in ViewState (if it doesn't have to be updated each time). A DataSet with 4000 records is clearly not a good candidate to store in ViewState. You could store it in the Cache, recreate it after each postback, or find ways to query fewer records on each call (but still not store them in ViewState).

Hope this helps a bit.

Imar

__________________
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Follow me on Twitter

Author of Beginning ASP.NET 4.5 : in C# and VB, Beginning ASP.NET Web Pages with WebMatrix
and Beginning ASP.NET 4 : in C# and VB.
Did this post help you? Click the button below this post to show your appreciation!