Hilton Giesenow's Jumbled Mind

Monday, November 01, 2004

ViewState vs Session State vs...

I was contributing to a discussion on sadeveloper.net a little while ago on storing information in viewstate versus session state. A user was asking about whether or not he should try and persist information between pages by using shared / static members within his page class.

First of all, as often occurs when one is stuck with an ASP.NET (or basically any server-side scripting model), the difficulty is in separating the paradigm between the stateful windows client and the disconnected, stateless web environment. As Carl Franklin regularly says - "by the time you see the page it is already forgotten about on the server". Yes, a shared / static member would persist the information between postbacks, but it would also store the same value for every user's visit to the page! What the person really wanted was to store the information just for that user on that page.

Now, another option in ASP classic days was to consider storing the data in a Session variable and to use some kind of key to specify that it was only for a specific page (e.g. "Index.asp:TransactionID"). This would work but the management is unneccesarily complex. If the user moves to another page the developer would either need to iterate through and clean every unneccesary session item or have memory bloat.

In ASP.NET we have another solution: Viewstate. For those very new to ASP.NET, viewstate is (at a simple level) the object / architecture that enables webcontrols to persist their value between postbacks. But, it offers quite a bit more. The Viewstate object is entirely accessible on the server and it works in a similar fashion to the Session object. It also operates as a Name-Value collection and it can also store any (serializable) object. The difference is that it is not stored on the server but rather streamed down to the client into a hidden form variable together with the various webcontrol properties (into that wierd long __VIEWSTATE field). As a result, it uses up more bandwidth but less memory. However, it exists within the page itself. If the user closes the window the Viewstate information is lost completely. This means that it does not hog server memory. Also, because it is independent of session, the user can leave a window open for a few hours (i.e. way past session timeout), post the form, and still receive the correct response!

Viewstate has some definitely benefits and disadvantages when compared to session variables and its use needs to be analysed carefully to suit the situation. Nonetheless, if used effectively, it can be another powerful tool in the asp.net developer's toolbox. One needs to be very careful of the total size of the page's viewstate, but the same is true for session information. In short - beware it exists and that it can be used for good but treat with thoughtfulness and understanding.


  • I love it. Great.

    By Anonymous Anonymous, at 3:00 AM  

Post a Comment

<< Home