Note: After reading this article, be sure to check out the followup article, "Using a STRUCT to make working with ViewState easier", where I take the ideas here and go one step further.
This is a big pet peeve of mine, so bear with me. I'll keep it short and to the point.
I'm a stickler for organized readable code and the use of ViewState is one of those things that can and should be standardized.
Typically you see developers directly access ViewState in the middle of doing other things. When you use this approach it means that when someone else reads through the code to maintain or enhance it, they have to look through all the code to see what is being placed in ViewState in order to know what they have to work with.
Let's jump right to my suggested approach and look at the code...
private int _EmployeeID = 0;
private byte[] _Version;
protected override object SaveViewState()
{
this.ViewState.Add("_EmployeeID", _EmployeeID);
this.ViewState.Add("_Version", _Version);
return base.SaveViewState();
}
protected override void LoadViewState(object savedState)
{
base.LoadViewState(savedState);
_EmployeeID = (int)ViewState["_EmployeeID"];
_Version = (Byte[])ViewState["_Version"];
}
Place the private variable declarations at the top of your module. You can follow immediately with the save and load overrides or move them elsewhere. I like having the save and load at the bottom of my code because I like to have my OnLoad be the first method in my code.
Why does it matter?
1. As I mentioned above it makes it easier for someone else to read your code and know what module level variables are being used. (Be sure to use a module level variable naming convention such as the _ prefix as well.)
2. ViewState is read once and written to once per variable rather than reading (and casting) it every time it's used in your code.
3. Because it makes you look like a professional. Seriously, take time to write clean organized code that follow standards and best practice approaches even when the module or page is very small.
[Edited 10/2/2007]
Alternate Approaches Suggested in the Comments Below
I like feedback and this post has some great feedback. My favorite, which honestly blew me away, is the attribute technique suggested by Tony. The full details can be found in the Code Project article, Using Attributes for encapsulating ASP.Net Session and ViewState variables. Declaring a variable on a page that is to be stored in ViewState is as simple as:
[PersistField(Location = PersistLocation.ViewState)]
protected int _EmployeeID;
To enable this you need to override the page class and create a custom attribute. If you already override the page class in your project then moving to this technique is almost a no-brainer.
What's so elegant about this besides the reduced about of code required, is that what you're doing is completely obvious since the variable is declared at the same place where you flag it for persistence via ViewState.
Another Approach
Michael Teper suggested the property approach.
private int _EmployeeId
{
get { return (int) ViewState["_EmployeeId"]; }
set { ViewState["_EmployeeId"] = value; }
}
If the attribute approach doesn't work for you, then this is probably the best way to handle ViewState, I've used it myself, but for some reason I've never changed my default coding approach to it. While this potentially reads values from ViewState multiple times, it doesn't do any reads if you don't use the property.