To maintain a consistent state for web server controls, ASP.NET provides you two powerful ways. As HTTP is stateless in its nature, we should use workarounds to ensure that our work and data are available between request. ASP.NET has two answers for this problem: View State and Control State.
Control’s View State is exactly the same hidden field on the generated HTML page as the page’s. In fact, Control State also uses the same hidden field.
What should you store in View State: as View State can be turned off for a page, you shouldn’t rely on it. The data or properties that are critical for your control (for example, the current index of a page) should be stored in Control State. Data related to the layout of a control should be stored in View State, but you should limit yourself. Pushing too much information into View State can result in slower postbacks, because View State information is send to the client, and then it’s sent back to the server. Sometimes it’s even encrypted, which makes the whole process more slower. Also, sensitive data shouldn’t be stored in View State, because it travels to the client’s computer, where it can be tampered with.
In today’s post, we’ll explore the various state management techniques ASP.NET provides. But first we need to underline the fact several times that HTTP is a stateless protocol. Being so, it provides huge scalability, but the programmers need to find some ways to store data (even forms) between page requests.
ASP.NET has several answers to this question:
- View State
- Query String
- Custom Cookies
- Session State
- Application State
- Control State
Now I’d like to examine the first six, because I plan to give the topic of caching a full post, and profiles are a bit different from the others.