Session Manager (post on post on post)

Today I read the Ran Wahle’s "Session manager" that was (kind of) response to Shlomo Goldberg’s post about a way to use the session state in type-safe way. Because I tried out both approaches but was only satisfied with another (slightly sharper approach to Ran’s) and I will be glad to share it too (as in all other fields, pick the best that works for you project in hand).

After several projects I have got to conclusion that there is no need for more than one object graph in the session, the more variables, the more your project get messy (without correlation of the method used). So, I’m designing a tree (each project by its own) that will contain the ‘sessional’ information. This leaves us with one (and only) session property to handle with the session state, all other properties are within the ‘root object’ tree (nested object-type properties).

My object will look like:

public class UserSessionInfo
{
    public const string SessionKey = "CurrentUser";

public string UserName { get; set; }

public ShppingCart Cart { get; set;}

//… other related properties …

}

The session initialization will take place in the AccountController (it is a project for learning the ASP.NET MVC using the default… ) right after successful login (in a method ‘SetUserSessionInfo’).

The other place is a ControllerBase, that is a controller that all other controllers derive from (if it was more complex project / WebForms may be another approach like IHttpModule or PageBase) and the initialization is done in ValidateUserSession that is called whenever the session is required from the Controller.Initialize method override (in this case is always but the login / register actions when the request is not authenticated). Of course (following Law of Demeter), I expose a protected property accessors for the properties (usually they will be readonly, but irrelevant for the discussion) like:

protected string UserName

{

    get { return m_currentUser.UserName; } // where ‘m_currentUser’ is a reference to the session object stored in the ValidateUserSession method.

}

Advanteges:

1. You / your team needs to handle only one object which is designed carefully and well thought off instead any one adding parameters here and there loosing the control.

2. This is the other side of ‘Single Responsibility Principle’ by Robert C. Martin, whereas only one object in the whole system (maybe a ‘parent’ object) is used to access ‘sessional’ information.

3. One may ask if it doesn’t have performance penalty because of all information stored in the session. Good question, but you can always leave a reference (like the Cart property) to null taking only the reference bytes (4 / 8) which is neglect able.

Disadvanteges:

Slightly more work of design and thinking… (or does it advantage ;-) )

And final notes about other implementations:

1. Using singleton tightly coupled your whole project to the type and the same instance, which is horrified for testing and it is the ‘most misused design pattern’ i have ever saw.

2. As a good citizen of .net, please forget that the keyword ‘sealed’ ever existed (future post), in this case (if it was written in .net 2 and up it could be ‘static’ class).

3. For the enum approach, I don’t think the ‘ToString’ performance is an issue, just an nondeterministic way to convert to string as it may be localized (currently it isn’t but who knows), using ‘Enum.GetName’ instead would help.

4. A nice wrapper around the session would be C# 3.0 extension methods around the HttpSessionStateBase type like:

public static UserSessionInfo CurrentUser(this HttpSessionStateBase session) { return session[UserSessionInfo.SessionKey] as UserSessionInfo; }

5. A warning: the expression “Session != null” can throw exception of “Session is not available…” in some cases, bad design by .net, but you need to take care.

Have fun!