Effective management of user state becomes difficult as the application grows during development. Available memory on the server decreases each time the developer decides to persist data in session object. This can have a negative impact on the application’s performance, as well as other applications that exist on the server.
Available memory is one consideration; however I will be focusing on the benefits of better organization of session objects. If you have not read the following article, do so now http://www.aspalliance.com/robertb/articles.aspx?articleId=4.
Generally speaking, each page on a web application may have a dataset or multiple datasets providing the data the user will be interacting with. Some of this data may be data that is general to the entire site; some of it may be specific to the page. View state may be one option for page specific data, but that’s a tangent for another time. What if you have a series of forms that take the user form point A to point E while collecting data from points B, C, and D in-between, such as a wizard assisting a user in filling out an employment application? What about a shopping cart that is available for the user while they are browsing different areas of the site? You may have created several different datasets, one for each page, maybe a few other objects to handle one-off bits of information, whatever the case, you may have ended up with ten, twenty, or thirty or so objects in session. What if you needed to clear out or test specific objects being stored in session and there are a dozen or so objects persisted? With the Singleton model, everything can be typed allowing you to access those objects using intelisense.
I recently deployed a management application that handles the admin tasks for all .NET deployed web apps for a certain client. This application handles users, roles, role memberships, as well as various application specific areas. When the user logs in to the management system, they must select a server, which provides a list of applications. The user then chooses an application to administer. This information is stored in one singleton object, and is made available to every page.
Below is a portion of my session object:
using System;
namespace CSharpWeb
{
///
/// Manages Session Objects
///
public class SessionManager
{
//Make the constructor private
private SessionManager()
{}
//Name of the session variable
private const string SESSION_MANAGER = "SESSION_MANAGER";
string _userName = "";
string _firstName = "";
string _lastName = "";
string _selectedAppConString = "";
string _server = "";
//For brevity, only the below public property is displayed...
//you get the idea, one public property for every private member.
public string UserName
{
get
{
return _userName;
}
set
{
_userName = value;
}
}
///
/// Gets the SessionManager object out of session and returns it to the caller.
///
/// Session Manager typed object
public static SessionManager GetSessionManager()
{
SessionManager sMngr;
if(System.Web.HttpContext.Current.Session[SESSION_MANAGER] == null)
{
sMngr = new SessionManager();
System.Web.HttpContext.Current.Session[SESSION_MANAGER] = sMngr;
}
else
sMngr = (SessionManager)System.Web.HttpContext.Current.Session[SESSION_MANAGER];
return sMngr;
}
}
///
/// Calling class, this could be a class, but normally would be the WebForm itself.
///
public class CallingClass
{
public CallingClass()
{}
///
/// Call here to retrieve relevant data from the data source.
///
public void FillData()
{
//Get the data out of session
SessionManager sMgr = SessionManager.GetSessionManager();
//Make the calls here to retrive the relevant data:
sMgr.UserName = "Retrived user's Name Here";
//Set other properties of the Session Manager.
/*
No need to put the Session Manager "Back Into Session." This is handled
because the object is in the Singleton model; the GetSessionManager() method
is static and the reference to the object in session is maintained.
*/
}
}
}
This is just a very small subset of the actual class, but I think my point has be made. You can easily extend this class to include typed datasets, additional properties, etc.... I now have available to me the currently logged in user’s information, the selected application’s connection string, and whatever other luggage may be necessary to carry around.
I have used this to maintain the current index of a DataGrid, handled a return to previous page, and managed the drill down into child pages. There are plenty of possibilities. This class could even be extended to allow for multiple session managers across the site, each having their own area of responsibility.