Mark Mintoff My superpower is common sense


Session Manager

How often do you find yourself needing to use Sessions when developing using ASP.Net C# and are absolutely antagonized at the sheer amount of validations which you end up making in order to use the Session as a property? The above, is simply annoying to implement, and as usual I have my own little wrapper class which not only simplifies implementation, but allows you to access the Session even from classes which do not make a reference to System.Web (handy if your DAC (Data Access Layer) needs to know a value on the Session (a LanguageID perhaps?). This post is divided into two parts:
  1. The Session Object
  2. The Session Manager (which comes with Page and UserControl extensions!)

SessionObject<T> The SessionObject is an object which will be stored in a static collection (on the Session Manager) used to acquire values from the session. The reason I am making use of an empty interface will become more apparent in the implementation of the SessionManager. A brief explanation: The Session property returns the current session which is being used. Hence this class requires the use of System.Web, but if you're anything like me, you would have created a separate Class Library with all your C# 3.0 Extensions in it and making a reference to System.Web here won't matter. Don't worry, you won't need to make a reference to System.Web in your Data Access Layer; I won't go back on my word. The Constructor puts together an object which consists primarily of a Session ID, or more commonly known as the Session's key (like "pageID" mentioned in the example above) and the Default Value which is to be returned, should the Session key not exist. The Get method, does what you usually do; returns a default value if the Session is null, or returns the Session object (typed!) if it does. The Set and Clear methods are pretty obvious in their intended functions.
SessionManager The SessionManager is the brains behind the whole setup, the controller which manages all the SessionObjects which will be present: At first look you will notice that this class is static, and hence single instance. This is to cater for two things:
  1. Instances will not be created for this class, hence less Garbage Collection
  2. Accessible from within static methods; particularly useful when you are using C# Web Methods for AJAX
In order to utilize Context.Session.SessionID (highlighted in red), I built the following simple class into my Extensions Library: The first two methods are overloads of each other, returning the SessionObject<T> highlighted above. There are two ways to acquire this (hence the overloads):
  1. Without a specified default value. This will utilize default(T).
  2. With a specified default value (with thanks to Lukas Pechar for the suggestion), which will return the specified default if the session is null. This is particularly useful if you wish to return "-1" as an integer's default, or true as a boolean default, or String.Empty as a string on and so forth.
That's all there is to it! The rest, are extensions! Usage within a Class Library: Usage within a Page/UserControl Go forth and manage Sessions easier!
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Comments (9) Trackbacks (0)
  1. There is a serious problem with this dude. The static dictionary is common to all users. Like that two different users are sharing the same data!!! I tested this!

  2. A quick fix would be to fix up the constructor:

    public static SessionObject SessionObject(string sessionID, T defaultValue)
    if (!HttpContext.Current.Items.Contains(sessionID))
    HttpContext.Current.Items.Add(sessionID, new SessionObject(sessionID, defaultValue));
    return (SessionObject)HttpContext.Current.Items[sessionID];


    And remove the static dictionary. I’ve not tested this in detail but it seems to be working well.

    • The commenting tool is removing the triangle brackets but you get the point I’m sure

    • I’m very sorry about this Luke. I had discovered this and completely forgot about updating the post. The key is to use the SessionID from the Session itself.

      I hope I wasn’t the cause of a huge headache mate!

      • Problem is you are still storing the session on the application level which is a security problem. You don’t want people to have access to the session of others. I know it’s improbably but you can test it. Static variables are shared by all users.

        • **Improbable not improbably.

        • Yes you are right. Static variables are shared by all users. That is one of their objectives. However, you seem to be misunderstanding what is stored on the static dictionary in the SessionManager. The session consists of a NameValue or KeyValue specification and what the dictionary is keeping track of is keys; not values. As you can see from this line:

          There is a KeyValue representation here which keeps the name of the session (along with the user’s unique sessionID) and an ISessionObject. The ISessionObject is the interface used by SessionObject<T>. What the SessionObject contains are Get and Set methods. As you can see from the Get and Set methods, they are making use of an object named “Session”:

          And as you can see, it is returning the Current Session from the HttpContext.

          Hence, rather than storing session VALUES on the static dictionary, what this is doing is storing session KEYS. Hence there isn’t the security problem you are envisioning. Unless of course a collection of keys consisting ONLY of words like “orderInProgress”, “loggedInUser”…etc would be considered unsafe.

Cancel reply

No trackbacks yet.