Sessions are an important part of any web application. Session is more of a concept than a Class or Object or Keyword. ASP.Net’s Page class allows you to store and retrieve variables from current user session in following way:

Session[“MyVariable”] = 2012;

Session is unique to a user’s browser session. When user opens your application in a browser, IIS assigns a Session ID (a guid like unique id) to the browser session. If user opens another browser (Firefox, Chrome, IE) from the same machine, IIS will assign a different Session Id to the newly opened browser session. Browser receives this Session Id and passes back to the server via Cookie for each request it makes. If your application is configured to maintain the cookie-less session then session id is passed as part of the URL for each request. When user opens your application from a different tab of the same browser then browser will use the same session Id. 

Within .Net the session is actually available from: HttpContext.Current.Session object. So, even when you use Session[“MyVariable”] in your code behind, you are actually accessing HttpContext.Current.Session[“MyVariable”] object.

The default practice is to use Session[“MyVariable”] type of syntax. But there are disadvantages to using this syntax:

1. The return value is object so you will have to cast it to the type you need.
2. You don’t know if the variable is set already or not, so you will have to check for null.
3. If there is typo in the string “MyVariable” – there is no compilation error and you may receive run time error.
4. There is no intellisense to find out what session variables are already available to you.

Hence, better practice should be to make use of Singleton pattern and create your own session class. This practice defies all the disadvantages listed above.

Create a class SiteSession like following. You can give it any name that you like:

[Serializable()]
public class SiteSession
{
    #region "Semi Singleton implementation"
    protected SiteSession()
    {
    }

    public static SiteSession Current
    {
        get
        {
            if (null == HttpContext.Current.Session)
                return null;

            if (null == HttpContext.Current.Session["SiteSession"])
            {
                HttpContext.Current.Session["SiteSession"] = new SiteSession();
            }
            return (SiteSession)HttpContext.Current.Session["SiteSession"];
        }
    }//Current
    #endregion

    public void Destroy()
    {
        HttpContext.Current.Session.Clear();
    }

    //now declare all session variables
    Public string CurrentState { get;set; }
    Public string UserName { get; set; }
    Public CustomObject CurrentObject { get; set; }
}

The class needs to be declared [Serializable] to store it in Session. And this class is stored in Session using its ‘Current’ property. It follows singleton pattern so you cannot create the instance of it and its only instance is stored in the HttpContext.Current.Session object. 

There are three session variables that are declared in above example – CurrentState, UserName, CurrentObject. In your code you can use them anywhere as SiteSession.Current.UserName or SiteSession.Current.CurrentObject. IntelliSense will show you the names as well as you do not have to do type-casting.

Please note that Session[“CurrentState”] or Session[“UserName”] is not equivalent to SiteSession.Current.CurrentState and SiteSession.Current.UserName. You should no more use Session[“MyVariable”] syntax. 

If you see any disadvantage using this method, please give your feedback.