Scott Mitchell looks at the benefits of and confusion around View State in Microsoft ASP.NET. In addition, he shows you how you can interpret (and protect) the data stored in View State.
Understanding ASP.NET View State
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Session variables are pretty much obsolete because there is too much processing to be done before Session state varaibles are available. For example, if you are trying to authenticate a user, you are probably using Application_AuthenticateRequest, or if you are Portal based, your initialization happens on Application_BeginRequest. These events are fired before HttpContext.Current.Session is created, and therefore all the fancy sessionState modes (in web.config) won’t do you no stinken good because you don’t have a stinken Session to stick yer stinken values in!!!!
You can use HttpContext.Current.Application to store your variables – just prefix (or postfix) the key name with the calling IP address, which allows you to save and retrieve values when HttpContext.Current.Session is not available, however, HttpContext.Current.Application can be flushed by any thing that the web server considers a trigger (such as touching the web.config), and therefore, your values may magically disappear. And HttpContext.Current.Application variables are not stored by any special sessionState modes.
You can just use HttpContext.Current.Items, but they are only good for the duration of the page request. This appears to be the favored for portals. Just reload your environment from the database everytime a user makes a request to the page.
Of course you can always use coookies or store the variables to a database table yourself, but that requires you to write your own management system or bloat your code by cutting and pasting the same management logic with exception handling (don’t laugh, I see this all the time by people considered experts in the field).
Ah hah! A long comes Viewstates – the magical silver bullet! But alas, it is on a page basis. This appears to be only good for a portal based solution. One web page that dynamically generates the content.
When oh, when, will someone deliver a clean solution to maintaining variables across the entire scope of a session, without having to write some clever work arounds due to the limitations of each of the above solutions? The last introduction of viewstate is pure nonsense. You must rearchitect your solutions to be portal based in order to preserve values across sessions without performing session management.
I predict the next “innovation” will be having a hidden window in a frame with an entry field that contains a global “viewstate”.
> Just reload your environment from the database everytime a >user makes a request to the page.
Problem solved? Works across a cluster too.
The database option is a good solution for a few reasons.
One, you should not be tying your server down by storing application data in memory.
Two, although slower, for clustered environments the database option solves the problem of state management. If the session attributes are stored in memory then you would have to find a way to route that session back to the server it originated on or lose the data.
Three, ASP.Net is OO so you can write a base class that does all of your database access for your session management once and inherit that when writing your code for future web forms in your application.
Viewstate works well when you have a web form that needs to go back to the server for some purpose and then reload itself. I don’t think its intended purpose is to be an end all be all of session state management in ASP.Net.
The hardest thing about building web applications is finding the best balance between information that can be passed throughout the application and information that absolutely has to be stored in some form of session state.
From my experience, the less information you store in memory for your web application the better off you will be in many ways. Your application can be more responsive because less memory is taken away from the server to store session related information. Most importantly your application will be able to scale better without having to rewrite it.