View state is one of those areas the one can use without actually understanding it. But dealing with view state correctly is mandatory when designing a custom control. “Design” in this case begins only after understanding view state technically and includes dealing with various view state implications, leveraging view state for advanced tasks, or gracefully falling back if view state is switched of.
However, trying to find a complete and sufficient coverage of view state turns out to be …, well. Anyway, those hints might help:
The starting point in MSDN for view state is probably “ASP.NET View State“. The better introduction may be “Understanding ASP.NET View State“, but it only covers ASP.NET 1.1.
You may also want to have a look at ”TRULY Understanding ViewState“. Despite falling short of its own claims (to give a complete coverage of the topic, yet view state persistence is omitted and security issues are missing), it’s written quite amusing and also explains some misuse scenarios.
To get a better feeling for the problem side (ever had a grid with a dataset containing 16000 rows in viewstate?), this link might provide some insight: “Death By ViewState” (“I get enough issues relating to bad perf caused by large viewstate that I felt like it is time to dedicate some blog space to it, so here is a typical problem description for this type of problem.”)
The article “Speed Up Your Site with the Improved View State in ASP.NET 2.0” talks about improvements in ASP.NET 2.0, yet it forgot to mention “ASP.NET 2.0 Page State Persister“. Persisters provide a way to manage view state persistence (aptly named, aren’t they?), e.g. in the session instead of on the wire (which causes other problems… — but this might become another post ).
And by the way, there is a new thing in ASP.NET 2.0, called control state. Which is much like view state (technically identical), but there actually is a difference. See ”Control State vs. View State Example“ to get a better idea.