1. It provides state information for a specific ASP.NET page. If you need to use information on more than one page, or across the web site, you should use another method for maintaining state. Other than view state.
2. Because viewstate information is serialized into XML and then encoded using base64 encoding which generate large amount of data. If view state contains large amount of data, it can affect performance of your page.
3. In data-driven pages that are refreshed from the data store on each post back, you should turn view state off to remove the large hidden field generated by data controls such as grid view control.
4. Some proxies and firewalls will prevent access to the page that contain large amount of hidden fields.
5. Some mobile devices do not allow hidden fields at all, therefore view state will not work for these devices.

How To: Save values in view state
To use the view state property, the ASP.NET web page must have a server form element 

Void Page-PreRender(object sender,EventArgs e) 
    {                                 
        Viewstate.add("TestData","testingviewstate"); 
    }

ArrayList MyArray = new ArrayList ( );                                            
MyArray  = (ArrayList )ViewState["userinfo"];

If(ViewState["font"] != null) 

1. No server resources are required, because view state is contained in a structure within the page code.
2. View state has simple implementation and does not require any custom programming to use it. It is on by default to maintain state data on controls.
3. Enhanced security features, because the values are hashed, compressed, and encoded for Unicode implementation, which provides more security than using hidden fields.

Disadvantages of using View state:

1. Performance considerations, because view state is stored in the page itself, string large values can cause the page to slow down when users display it and when they past it.
2. Device limitation, mobile devices might not have the memory capacity to store a large amount of view state data.
3. Security risks, although view state stores data in a hashed format, it can still be tampered with, the information in the hidden field can be seen if the page output source is viewed directly.

View state chunking
View state data can become very large, in some cases. Because view state data is stored in hidden fields, some proxies and firewalls will prevent access to the pages that contain them. So ASP.NET 2.0 framework introduced a feature called view state chunking.

View state chunking is the process of splitting the data into chunks and put the data into multiple hidden-form fields, instead of transferring the data in large blocks.

To enable view state chunking, set the "MaxPageStateFieldLength" property to the maximum size that you want to allow in a single view-state field. When the page is postback to the server, the page parsers the view-state string at page initialization and restores property information in the page. The default setting is -1, which means that there is no maximum size and view state will not be broken up into chunks.

Security in View state
View state is stored on the page in a hidden field and is encoded using base64 encoding. In addition, a hash is created from the data using a machine authentication code MAC key. The hash value is added to the encoded view state data and the resulting string is stored on the page. When the page is postedback to the server, the ASP.NET framework re-hashes the view state data and compares the hash with the hashed stored previously in the page. If the hash dose not matches an exception is raised indication that view state data might be invalid.When ASP.NET framework creates a hash for view state data. It uses a MAC key that is

1. Auto-generated.
2. Specified in the Machine.Config file.

If the key is Auto-generated, it is created base on the MAC address of the computer, ASP.NET uses SHA1 encoding to create a large key. In a web-form environment, the key must be the same across all the servers. If the key is not the same, and the page is postback to a different server than on that created the page, on exception will be raised. So you should specify a key I machine.config instead of Auto-generation.

Encryption
While MAC encoding helps prevent tampering with view state data. It dose not prevent people from viewing this data in two ways

1. Transmitting the page over SSL: This will prevent data-packet sniffing and un-authorizing access.
2. Encrypting the view state data because SSL decrypts the page to display it in the browser, you should en encrypt the view state data, because these data might contain sensitive information such as SSN or IDs.

To encrypt the data, set the page's ViewStateEncryptionMode property to true, and the page handles all encryption and decryption for you.

Pre-user View state encoding
If your web site authenticates users, you can set the ViewStateUserKey property in the Page-Init event handler to associate the pages view state with a specific user. You must set the ViewStateUserKey to a unique value for each user, such as the user name or identifier. This will prevent one-click attacks in which a malicious user creates a valid, pre-filled page with view state data previously created page. The attacker then lures a victim into clicking a link that sends the page to the server using the victim's identity.