Why would you ever use asp.net's ViewState storage object over the Session storage object?

Question

Other than because session storage is session-global to more than one page, why would you ever want to use the viewstate to hold values?

It seems kind of ridiculous

Answer 1

The whole reason for Viewstate or Session is to turn the web from a stateless system into a dynamic, customized experience. When a user requests a page, the only way you can resume where the user left off in their experience is to remember the state either on the server or on the user's client.

Viewstate is a mechanism for remembering the user's state on the client. Session is a mechanism for remembering the user's state on the server.

Viewstate is a transient storage mechanism. Controls that use viewstate have their state rendered into the html page as a hidden input. To prevent tampering, it is signed. It is not encrypted, however, so you probably want to avoid putting ANYTHING sensitive in there. Viewstate is useful for situations where you want to post across series of multiple requests (page loads). An example of this is when a form doesn't validate because maybe the user entered a bad email address or something, and you want to restore the form as it was before the user submitted. The downsides to this is that viewstate is a hungry beast and can easily add 30-50% to page size.

Session, on the other hand, is stored on the server. The client gets a token that tells the server which block of memory is theirs. This can be much more secure than viewstate because the data isn't being retransmitted to the user over and over. There are trade-offs though. Your server can run out of memory. Or, the user could lose the data if their session is disrupted.

Generally, there's no "right" answer on which to use. It is all about what you are trying to accomplish.

Most things to do with controls should use Viewstate. IF you're dealing with sensitive information however, consider Session. If you have data that is for a specific set of pages, use viewstate. If it is data that you will need throughout a user's visit on your site, considier Session.

Answer 2

ViewState and Session have different scopes. ViewState is designed to store more or less transient data, during "postbacks", while session is used to save critical session state data. I recommend using ViewState for state related to a specific "page session".

If you don't like the normal behavior of ViewState, it's pretty simple to write your own PageStatePersister and let this object perform persistence, for instance using session, or something like Memcached. You can then completely override the default persistence mechanism.

Then, the good thing is you can seamlessly continue to use standard web controls in the .NET Framework, which will all use ViewState/ControlState for this type of data, without bloating the ViewState. A server memory persistence mechanism could be very efficient.

Answer 3

Sessions run out, Viewstate does not - you can go back an hour later and your viewstate will still be available. Viewstate is also consistently available when you go back/forward on the website, Session changes.

Answer 4

Not really a direct answer to your question, but it may resolve your issue.

You can store viewstate server side, eliminating the payload for the client.

Create a class the inherits page, and override the PageStatePersister. http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister.aspx

 public class RussPage : Page
    {
         protected override PageStatePersister PageStatePersister
        {
            get
            {
                return new SessionPageStatePersister(Page);
            }
        }
    }

Answer 5

You are doing an app where viewstate bloat, for the most part, is not an issue, then it's better to store page specific data in the viewstate because it helps your server perform better. If you go crazy with session, or any caching, for that matter, you can hurt yourself more then you help yourself.

Answer 6

ViewState is essentially just a hidden input that must be uploaded to the server and parsed with each request. This field is typically populated automatically, often with the programmer blissfully unaware, and can grow quite large. For many sites that presents a problem, because even broadband users have very limited upstream bandwidth.

On intranet sites where all the users have high-speed LAN access to the server but the ram available for holding session data is limited, it may make more sense.