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 to send any kind of information other than a few small query string like values, back and forth from the client to server. I mean what a waste of bandwidth(!), simply for storage purposes. The session, while global across multiple pages, seems like a completely superior alternative to the viewstate.

Especially with asp.net ajax controls and variants, the viewstate could quickly become bloated tracking the various states and variables of all those different controls and html elements.

But then why is there viewstate storage for page variables and objects at all?

Maybe I'm missing another great usage for the page's viewstate storage, does anyone know something out there?

Thanks for reading!

EDIT: Everyone had a great answer, sorry if I didn't pick yours.

Adrienadriena

Answer 1

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.

Dolerite

Also, sessions are basically key-value pairs: if your user opens multiple tabs, and you're storing an ID in session, you're going to have problems. – Blasien

Answer 2

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.

Warfourd

I kind of addressed this in the question. But I kind of think that 9 times out of 10, it makes more sense to use a unique key stored on a page to put variables in the session, than to use the viewstate at all. I think that the session is the "right" answer, because you don't burden the bandwidth. – Adrienadriena

Very well put: "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." +1 – Elston

Eh, that's the basic official documentation, but my question was kind of focused about how the default implementation of page view seemed poorly designed. Like many of the small pieces of the .net CLR have design flaws, though the vast chunk of it is pretty solid. – Adrienadriena

Answer 3

For example when your application might be running in a computer farm and you can't configure session to use sql server.( Or using sql server is too much of a performance hit)

Neslund

You wouldn't want your farm to use a database to store session anyhow, it'd be slower than just using sticky IP's. Session is bad for a site that wants to scale beyond a few users. – Foldboat

You can also use a Session Server. This is much faster and will maintain session for all the servers in a farm without the SQL Session overhead. – Elston

@Guy, yes you can. But this is also not always possible. And it is much easier just to save small piece of information in viewstate then purchase additional server and configure it as Session server. – Neslund

Yes, in the case of using SQL to store your session, you would not want to store ViewState in session. Regular session is slow enough, but adding ViewState to that would be pretty damning. – Botticelli

Answer 4

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.

Jimerson

Hmm, yeah I didn't know the thing about the PageStatePresister. Thanks for the info. – Adrienadriena

Answer 5

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.

Gustin

Answer 6

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);
            }
        }
    }

Botticelli

I didn't either until about 2 years ago. I found this to be my "happy place" when it came to the ViewState vs. Session question. – Botticelli

Doesn't it say that you just save viewstate information in session? Then why don't you just do it directly? – Neslund

Doing this breaks tabbed, windowed or otherwise "multitasking" browsing of a site! Session is shared among multiple tabs open to the same site, ViewState is not. – Fuze

@Jeffrey Hantin - Fair enough. And if you’re working in that type of environment you need to take that into account. You can create different "Page" subclasses for cases like this. Any programming case needs to be looked at and design decisions made based on the situation. – Botticelli

Answer 7

Not an answer to your question but one of your assumptions is incorrect.

Session IDs can be passed in the URL. Session does not require cookies.

http://msdn.microsoft.com/en-us/library/aa479314.aspx

<sessionState cookieless="true" />

Winding

Although this is an old topic, ASP.NET security is often glossed over so here goes: in general, cookieless="true" is frowned upon due to security concerns (see Keep sensitive information out of the URL: owasp.org/index.php/…) because the session is passed in full view on the URL. Dino mentions this in the article: msdn.microsoft.com/en-us/library/… – Hamon

Answer 8

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.

Neddra