When I browsing through Internet I came across very good article : View State improvement made in .NET 2.0.
In this article is not going to expol the benefits of view state. this article will explain you whats improved for ViewState in .NET 2.0.
Couple of things to keep in mind: Turn off view state when its not needed and secondly ask yourself if its cheaper to requery the database or cache the queried data and data-bind on each request instead of using view state (data controls by their very nature generate significant view state).
One of the most frustrating aspects of working with server-side controls in ASP.NET 1.x is the all-or-nothing mentality with respect to view state. Behavioral aspects of controls like pagination in the DataGrid or selection change notifications in textboxes require view state to be enabled to function properly. I’m sure all of you are sufficiently daunted by the prospect of leaving view state enabled in any of your DataGrids at this point. In ASP.NET 2.0, Microsoft addresses this particular problem by partitioning the view state into two separate and distinct categories: view state and control state.
Control state is another type of hidden state reserved exclusively for controls to maintain their core behavioral functionality (SelectedIndex in a ListBox is an essential bit of information), whereas view state only contains state to maintain the control’s contents (UI). Technically, control state is stored in the same hidden field(__VIEWSTATE) as view state (being just another leaf node at the end of the view state hierarchy), but if you disable view state on a particular control, or on an entire page, the control state is still propagated. Control state allows a control to intelligently split their state into what is absolutely required and what is not. The nice aspect of this implementation is that we can now amend our original principle on optimizing view state for ASP.NET 2.0 to be much stronger: if you populate the contents of a control every time a page is requested, you should disable view state for that control.
As long as control builders properly partition their state into behavioral state (to maintain core functionality) and UI state (to retain contents), this statement should be followed religiously. I would like to tell you to start following this recommendation now with all work done in ASP.NET 2.0, but the DataGrid has not been refactored to keep its behavioral state in control state. Fortunately, the new GridView is the logical successor to the DataGrid and it uses control state properly, as do the new versions of the TextBox and DropDownList controls. following figure shows a list of the controls that currently make use of control state and what properties they store there for your reference.
The next thing I wanted to point out are the serialization improvements in v2.0. View state (and control state) serialization now uses a new mechanism implemented in ObjectStateFormatter instead of using LosFormatter. the new serializer serializes the same object graph into roughly half the size, and spends about half as much time in the serialization and deserialization process.
No more text: LosFormatter wrote to a TextWriter; ObjectStateFormatter writes to a BinaryWriter. This by itself doesn’t do much, other than it enables a some other improvements.
Token-based approach: LosFormatter wrote out strings to represent data types and embedded the data within <, > brackets. None of that anymore. ObjectStateFormatter capitalizes on the underlying binary model, and writes out a byte representing the following data, and then the data.
No more strings: The old formatter converted everything to strings (numbers, booleans etc.) to write into the TextWriter. The new one writes out bytes. This saves the cost of converting to and from a string.
More compact storage: Integers are stored as 7-bit encoded numbers. So most of them (values 0 – 255) just take a single byte instead of 4. In the case of booleans, there are simply two boolean-type tokens: a true one and a false one, so there is no additional cost to storing boolean data. DateTime is also special cased. Just the TickCount is saved, which by the way isn’t lossy as the string version is.
Indexing of strings: Lets say you had a DataGrid with a 100 cells. You’d have the word “Text” in view state a 100 times! This came from the Text property of TableCell. The StateBag type (that is used for ViewState) now saves property names using IndexedString. The ObjectStateFormatter special cases this type (like Pair and Triplet) to build a running table of strings. Each time a string is reused, it simply saves out a token referring to an IndexedString, and the index within this running table.
If we place a DataGrid on a form and bind it to the authors table in the pubs database, the size of the view state string in 1.x is 12,648 characters. If we do the same in 2.0, the size of view state is reduced to 6,728 characters, a reduction of nearly half. Following Figure shows the contrast in space required by view state in ASP.NET 1.x, ASP.NET 2.0, and the number of characters actually rendered to the page for a variety of input sizes.
View State Size Comparison
Without doing anything special, you can look forward to an immediate reduction in the size of your view state with the release of ASP.NET 2.0. This does not mean that you should stop thinking about whether your controls need view state to function properly or not, since it can still contribute significantly to the size of the response, as evidenced in Figure.
Nikhil Kothari’s Weblog