View State: do not forget to manage!

View State is an essential part of ASP.NET and not paying proper attention to how it's set up in your web application can give you some surprises sometimes not very pleasant ones. For those who wants to refresh their memory about ASP.NET View State I recommend to start from this good article by Dino Esposito. The article is not very new but it's still relevant and it covers many topics that are actual for today's ASP.NET programming.

So now as the background is covered I would like to focus on two main aspects that have to be considered in regards to the View State: performance and security.

What is it to consider performance-wise in regards to the View State? In a nutshell as larger the View State as larger a browser payload as more time is required to process the page on both server and client side meaning worse user experience.

What does the View State have to do with security? As the View State is publicly exposed to a web browser and contains internal data of the ASP.NET page and user controls there is always a risk that its content can be altered and data compromised that could lead to some unexpected behavior of a web application.

So is it inefficient and dangerous to use the View State in your application? Answer is NO: the View State is extremely useful and sometimes absolutely essential for the ASP.NET web application to work properly but don't assume that the default View State settings and behavior are always the best choice for you: always manage them consciously.

Is there best practice about the View State? Of course and there are some of them.

1. Always explicitly turn off the View State for any control that does not require it to operate. Examples are: Label control, Literal control, Image control, HyperLink control, etc.
2. If your page does not perform a post back and there is no complex data binding there is a good chance that you can turn off the View State for the entire page in the @Page directive. If you doubt simply try and see how the page works with the View Stated turned off.
3. If you use complex template based server controls like Login control or CreateUserWizard control, for instance, convert them to templates and check out that the View State of all the child controls is properly managed (always look for Labels and Literals).
4. When optimizing your ASP.NET application use some third-party browser-based tools to analyze page's View State content and reduce its size as much as possible.
5. If you use a client-side View State always encrypt it.
6. Consider moving the View State to a server side: besides security benefit of not exposing the View State publicly and reduced http payload the View State is processed faster on the server. Be aware about server memory consumption when using the View State on the server side. It's much easier to implement the server-side View State in ASP.NET 2.0 then it was with ASP.NET 1.1. Look at the example here.

That's mostly it. Follow the best practices above and feel confident about having your web application's View State managed properly.