As far as web developers are concerned, the web is stateless. This statement will serve as the cornerstone of our entire discussion of view state. Therefore I’ll say it again—as far as we are concerned, the Web is stateless.
For example, you request an ASP.NET page from a web server. Once the page is processed on the server and returned to you that same server does not remember the page anymore. Even a slight page postback initiates the same request sequence and the web server performs the same task again as if it never saw this page in the first place. This is the grand difference between web applications and their desktop counterparts. On the desktop you can maintain state between requests. On the web it’s a much harder task.
How do you retain text in input boxes, selections of dropdown controls, etc? To maintain state on the web you need help. ASP.NET goes a long way giving you the necessary support to carry on the page state from one request to another, and it does so seamlessly. Sometimes so seamlessly that you may overlook a large chuck of text you drag around. Hold this thought. We’ll get back to it shortly.
To summarize view state’s mission in once sentence—view state helps you maintain values through subsequent requests of the same (!) page.
ViewState does not hold the controls, rather it holds the values of the form controls and their corresponding ID’s that would otherwise be lost due to a post back because they do not post with the form. ViewState is not used to hold session data or to transmit data between pages. ViewState does not recreate the dynamically created controls of a page. It does not restore the values to the controls after a post back operation. Taken aback? Yes, it is true. Even when the ViewState for a control is disabled, still the value would be retained after a post back of the page occurs, for input controls like TextBox or DropDownList. So then, what is ViewState? ViewState represents the state of a page when it was last processed on the web server. It holds the values of a control that has been dynamically changed
It maintains the state of a page as it travels back and forth. There is no more need to worry about restoring values of page controls between postbacks.
How does ViewState work?
All server controls have a property called ViewState. If this is enabled, the ViewState for the control is also enabled. Where and how is ViewState stored? When the page is first created all controls are serialized to the ViewState, which is rendered as a hidden form field named __ViewState. This hidden field corresponds to the server side object known as the ViewState. ViewState for a page is stored as key-value pairs using the System.Web.UI.StateBag object. When a post back occurs, the page de-serializes the ViewState and recreates all controls. The ViewState for the controls in a page is stored as base 64 encoded strings in name – value pairs. When a page is reloaded two methods pertaining to ViewState are called, namely the LoadViewState method and SaveViewState method. The following is the content of the __ViewState hidden field as generated for a page in my system.
Listing 1
<input type="hidden" name="__VIEWSTATE" value="dNrATo45Tm5QzQ7Oz8AblWpxPjE9MMl0Aq765QnCmP2TQ==" />
Where Is View State Stored?
View state is simply text. It is an aggregate of values of controls on a page. It’s a string that contains values of page controls hashed and encoded in some manner. The view state contains no information about the server or the client. It only comprises information about the page itself and its controls. It lives along with the page in the user’s browser.
As a rule, view state is stored right in the page and therefore it travels with it back and forth. Remember good old hidden input fields? View state is nothing more than a hidden input which holds a hash of control values. If you view the source of an ASP.NET web form you will see something like this:
<input type="hidden" name="__VIEWSTATE"
value="CEbzzzEnmmz+Bc8IDFlnpgCLJ/HB00...>
Nobody in sane mind can read these strings fluently. What you see here is a base64 encoded string. I emphasize encoded because some folks assume view state is encrypted. Base64 is not an encryption algorithm. Base64 makes a string suitable for HTTP transfer plus it makes it a little hard to read. Just a little. It’s easy to decode this string and see what’s inside. Can this be a security issue? It sure can. We’ll address your concern in due time. Stick around.
Every server control ultimately derives from the Control class. Be it a WebControl, HtmlControl or even LiteralControl it has a property called EnableViewState. When a page is built every control that has this property enabled contributes to the view state by serializing its contents (in this case: converting its contents into a string). Now, some controls are easy to serialize, while others might give us grief.
What manages the view state is the StateBag class. This class is like a dictionary—you may store key/value pairs in it. This is how you store a piece of useful data in the view state:
ViewState ["SortOrder"] = "email"
When the page posts back its view state is taken apart (decoded) on the server and each control participating in the view state gets its value restored.
Suppose you have an empty dropdown list which you populate with user names from the database. When the page runs for the first time (!Page.IsPostback. Rings a bell?) you need to databind it and fill it with user names. What happens once the page loads? Without view state the dropdown list will be empty. As you enable view state the dropdown list content will be restored on postback. Or… you would have to populate the list from the database every time the page posts back! If you weigh database access vs. view state the scale tips in favor of view state (unless the list of users is so huge that you’d rather ping the database each time instead of dragging around a giant view state string)
Arrao4u 