Introduction
Just about every ASP.NET application needs to keep track of data for a user's session. ASP.NET provides the HttpSessionState
class to store session-state values. An instance of the HttpSessionState
class for each HTTP request is accessible throughout your application using the static HttpContext.Current.Session
property. Access to the same instance is made simpler on every Page
and UserControl
using the Session
property of the Page
or UserControl
.
The HttpSessionState
class provides a collection of key/value pairs, where the keys are of type String
and the values are of type Object
. This means that Session
is extremely flexible and you can store just about any type of data in Session
.
But (there is always a but) this flexibility does not come without a cost. The cost is the ease with which bugs can be introduced into your application. Many of the bugs that can be introduced will not be found by unit testing, and probably not by any form of structured testing. These bugs often only surface when the application has been deployed to the production environment. When they do surface it is often very difficult, if not impossible, to determine how they occurred and be able to reproduce the bug. This means they are very expensive to fix.
This article presents a strategy to help prevent this type of bug. It uses a Design Pattern called a Facade, in that it wraps the very free interface provided by the HttpSessionState
class (that can meet the requirements of any application) with a well designed and controlled interface that is the purpose built for a specific application. If you are not familiar with Design Patterns or the Facade pattern, a quick internet search of "facade design pattern" will provide you with plenty of background. However, you do not have to understand design patterns in order to understand this article.
The example code shown in this article is written in C#, but the concepts are applicable to any .NET language.
What is the Problem?
In this section of the article, I will describe the problems with direct access to the HttpSessionState
class, without the facade. I will describe the kinds of bugs that can be introduced.
The following shows the typical code written to access session-state variables.
Session["some string"] = anyOldObject;
DateTime startDate = (DateTime)Session["StartDate"];
The problems arise from the flexible interface provided by HttpSessionState
: the keys are just strings and the values are not strongly typed.
Using String Literals as Keys
If string literals are used as the keys, the string value of the key is not checked by the compiler. It is easy to create new session values by simple typing errors.
Session["received"] = 27;
...
Session["recieved"] = 32;
In the code above, two separate session values have been saved.
Most bugs like this will be identified by unit testing – but not always. It may not always be apparent that the value has not changed as expected.
We can avoid this kind of bug by using constants:
private const string received = "received";
...
Session[received] = 27;
...
Session[received] = 32;
No Type Checking
There is no type checking of the values being stored in session variables. The compiler cannot check correctness of what is being stored.
Consider the following code:
Session["maxValue"] = 27;
...
int maxValue = (int)Session["maxValue"];
Elsewhere the following code is used to update the value:
Session["maxValue"] = 56.7;
If the code to read the "maxValue
" session variable into the maxValue int
variable is executed again there will be an InvalidCastException
thrown.
Most bugs like this will be identified by unit testing – but not always.
Re-using a Key Unintentionally
Even when we define constants on each page for the session keys, it is possible to unintentionally use the same key across pages. Consider the following example:
Code on one page:
private const string edit = "edit";
...
Session[edit] = true;
Code on a second page, displayed after the first page:
private const string edit = "edit";
...
if ((bool)Session[edit])
{
...
}
Code on a third, unrelated, page:
private const string edit = "edit";
...
Session[edit] = false;
If the third page is displayed for some reason before the second page is displayed, the value may not be what was expected. The code will probably still run, but the results will be wrong.
Usually this bug will NOT be picked up in testing. It is only when a user does some particular combination of page navigation (or opening a new browser window) that the bug manifests.
At its worst, no one is aware that the bug has manifested, we may just end up modifying data to an unintended value.
Re-using a Key Unintentionally - Again
In the example above, the same data type was stored in the session variable. Because there is no type checking of what gets stored, the problem of incompatible data types can also occur.
Code on one page:
Session["FollowUp"] = "true";
Code on a second page:
Session["FollowUp"] = 1;
Code on a third page:
Session["FollowUp"] = true;
When the bug manifests, there will be an InvalidCastException
thrown.
Usually this bug will NOT be picked up in testing. It is only when a user does some particular combination of page navigation (or opening a new browser window) that the bug manifests.
What Can We Do?
The First Quick Fix
The first and most simple thing we can do is make sure we never use string literals for session keys. Always use constants and so avoid simple typing mistakes.
private const string limit = "limit";
...
Session[limit] = 27;
...
Session[limit] = 32;
However, when constants are defined locally (e.g. at page level), we might still re-use the same key unintentionally.
A Better Quick Fix
Rather than define constants on each page, group all session key constants into a single location and provide documentation that will appear in Intellisense. The documentation should clearly indicate what the session variable is used for. For example, define a class just for the session keys:
public static class SessionKeys
{
public const string Limit = "limit";
}
...
Session[SessionKeys.Limit] = 27;
When you need a new session variable, if you choose a name that has already been used you will know this when you add the constant to the SessionKeys
class. You can see how it is currently being used and can determine if you should be using a different key.
However, we are still not ensuring consistency of data type.
A Much Better Way - Using a Facade
Only access the HttpSessionState
from within one single static
class in your application - the facade. There must be no direct access to the Session
property from within code on pages or controls, and no direct access to HttpContext.Current.Session
other than from within the facade.
All session variables will be exposed as properties of the facade class.
This has the same advantages as using a single class for all the session keys, plus the following advantages:
- Strong typing of what gets put into session variables.
- No need for casting in code where session variables are used.
- All the benefits of property setters to validate what gets put into session variables (more than just type).
- All the benefits of property getters when accessing session variables. For example, initialising a variable the first time it is accessed.
An Example Session Facade Class
Here is an example class to implement the Session facade for an application called MyApplication
.
public static class MyApplicationSession
{
# region Private Constants
private const string userAuthorisation = "UserAuthorisation";
private const string teamManagementState = "TeamManagementState";
private const string startDate = "StartDate";
private const string endDate = "EndDate";
# endregion
# region Public Properties
public static string Username
{
get { return HttpContext.Current.User.Identity.Name; }
}
public static UserAuthorisation UserAuthorisation
{
get
{
UserAuthorisation userAuth
= (UserAuthorisation)HttpContext.Current.Session[userAuthorisation];
if (
userAuth == null ||
(userAuth.Created.AddMinutes(
MyApplication.Settings.Caching.AuthorisationCache.CacheExpiryMinutes))
< DateTime.Now
)
{
userAuth = UserAuthorisation.GetUserAuthorisation(Username);
UserAuthorisation = userAuth;
}
return userAuth;
}
private set
{
HttpContext.Current.Session[userAuthorisation] = value;
}
}
public static TeamManagementState TeamManagementState
{
get
{
return (TeamManagementState)HttpContext.Current.Session[teamManagementState];
}
set
{
HttpContext.Current.Session[teamManagementState] = value;
}
}
public static DateTime StartDate
{
get
{
if (HttpContext.Current.Session[startDate] == null)
return DateTime.MinValue;
else
return (DateTime)HttpContext.Current.Session[startDate];
}
set
{
HttpContext.Current.Session[startDate] = value;
}
}
public static DateTime EndDate
{
get
{
if (HttpContext.Current.Session[endDate] == null)
return DateTime.MaxValue;
else
return (DateTime)HttpContext.Current.Session[endDate];
}
set
{
HttpContext.Current.Session[endDate] = value;
}
}
# endregion
}
The class demonstrates the use of property getters that can provide default values if a value has not been explicitly stored. For example, the StartDate
property provides DateTime.MinValue
as a default.
The property getter for the UserAuthorisation
property provides a simple cache of the UserAuthorisation
class instance, ensuring that the instance in the session variables is kept up to date. This property also shows the use of a private setter, so that the value in the session variable can only be set under the control of facade class.
The Username
property demonstrates a value that may once have been stored as a session variable but is no longer stored this way.
The following code shows how a session variable can be accessed through the facade. Note that there is no need to do any casting in this code.
MyApplicationSession.StartDate = DateTime.Today.AddDays(-1);
DateTime startDate = MyApplicationSession.StartDate;
Additional Benefits
An additional benefit of the facade design pattern is that it hides the internal implementation from the rest of the application. Perhaps in the future you may decide to use another mechanism of implementing session-state, other than the built-in ASP.NET HttpSessionState
class. You only need to change the internals of the facade - you do not need to change anything else in the rest of the application.
Summary
The use of a facade for HttpSessionState
provides a much more robust way to access session variables. This is a very simple technique to implement, but with great benefit.
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.