How do you handle Session variables?
One of my many pet peeves is working with Session variables that are treated as Strings. For instance, when I see something like this:
tbFirstName.Text = Session[”FirstName”].ToString();
Why? Well, because a typical application has zillions of Session variables and using this methodology means that there's no easy way to determine what all the session variables are and you run the risk of misspelling them. This also means that there's a good chance that you are going to have two or more session variables that store essentially the same information. I've heard the argument that if you are careful, document your code, blah blah blah that this is an 'ok' methodology, but the question that begs to be asked is “WHY?” Ok, if you really bend over backward then the above argument is true. But just because it's manageable doesn't means it's a good way to handle things.
Two things come to mind in handling Session variables. First, get them out of your pages. Huh? Well, as i learned from my friend Phil Hunt at TiBA Solutions , you can use an area specific BasePage (which may or may not inherit from a global BasePage), and handle Session variables via properties in the base page. This has the benefit of centralizing your code, strongly typing session variables, allowing for null checks, default values etc without having to rewrite the code all over the place and elminating the possibility of spelling mistakes. Plus, since it gives you intellisense support, you or a newer developer can do a lot better job at finding and guessing what session variables are available.
One other thing I'd recommend though is creating a class that holds the actual strings used in the session variables. Since these are as static as can be, I'm not using Get/Set accessor (this is probably the only case I wouldn't) b/c it really doesn't matter much. Just to be pure, I'd probably go back and add accessors later but essentially, I recommend as one approach, creating a class to hold your session variables in , then nest another class for each functional area like so:
public class SessionVariables
{
public SessionVariables()
{
}
public class Authentication
{
public static String UserName = "UserName";
public static String EncryptedPassword = "EncryptedPassword";
}
public class SearchValues
{
public static String BeginDate = "BeginDate";
public static String EndDate = "EndDate";
}
}
Now you can reference session variables like this:
String UserName = Session[SessionVariables.Authentication.UserName].ToString();
This is actually the code I'd stick in the base page accessors so you don't reference it in the pages. I know, this is hardly groundbreaking stuff, it's old as dirt. But I still run into quite a few applications that have Hard coded session/view/querystring variables and well, it's not something that ought to be.
So far, this is one of the most straightforward ways to get the desired results, but I'm not claiming it's the best. If anyone else has any suggestions that get you to the same place, please let me know.