C＃/ ASP.NET-在会话中存储通用列表VS会话中的单个变量

Question

I have seen many "wrapper" classes for the ASP.NET Session state and some do something like:

Strongly Typed Layer (Pseudo Code #1)

public class MySession
{
    public int MyID
    {
        get
        {
            return Convert.ToInt32(HttpContext.Current.Session["MyID"]);
        }
        set
        {
            HttpContext.Current.Session["MyID"] = value;
        }
    }
    public string MyName
    {
        get
        {
            return (HttpContext.Current.Session["MyName"]).ToString();
        }
        set
        {
            HttpContext.Current.Session["MyName"] = value;
        }
    }
    ...

    public MySession()
    {
        // Could be static or instantiated depending on needs...
    }
    ...
}

///// USAGE IN OTHER CLASS /////

MySession currSession = new MySession();
currSession.MyID = 5;
currSession.MyName = "John Doe";

Console.WriteLine($"{currSession.MyName}'s ID = {currSession.MyID}");

Then I have seen others do something like:

Generic List Variant (Pseudo Code #2)

public class SessionVariables
{
    public int MyID
    {
        get;
        set
        {
            MyID = value;
            MySession.SaveVariables();
        }
    }
    public string MyName
    {
        get;
        set
        {
            MyName = value;
            MySession.SaveVariables();
        }
    }

    ...
}

public class MySession
{
    public static List<SessionVariables> Variables;

    // Might be private in real application environment
    public MySession() // Could be static or instantiated depending on needs...
    {

        if (HttpContext.Current.Session["MyVariables"] == null)
        {
            HttpContext.Current.Session["MyVariables"] = new List<SessionVariables>();
        }

        // Obviously more appropriate checking to do here, but for simplicity's sake...
        Variables = (List<SessionVariables>)HttpContext.Current.Session["MyVariables"]

    }

    public static void SaveVariables()
    {
        HttpContext.Current.Session["MyVariables"] = Variables;
    }
    ...
}

///// USAGE /////

public class MyPage
{
    public void MyMethod()
    {
        MySession currSession = new MySession(); // Create variables

        MySession.Variables.MyID = 5;
        MySession.Variables.MyName = "John Doe";
        Console.WriteLine($"{MySession.Variables.MyName}'s ID = {MySession.Variables.MyID}");
        ...
    }
}

---

Thoughts

Obviously, these examples are both pseudo code style (so please ignore general errors), but they illustrate some of the approaches to building a data access layer for the Session state.

I do something similar to the first variant, albeit, with a more comprehensive data type mapping/conversion plan. I use a an "normal" class to wrap Session in, but it could easily be static since the properties will pull from the Session state when their "get" is called and thus never be out of sync since the class actually doesn't hold any data itself.

The second seems more "overkill" to me from first impressions since yes, you are only storing one variable in the Session state, but it clutters up the rest of the code by forcing code to be making references to the list:

myObject.TheList.VariableIWant
VS
myObject.VariableIWant

of which I prefer the later (just looks cleaner), though this could easily be hidden in a super class or just making a local variable directly reference the list:

new MySession(); // Create the variables
List<SessionVariables> mySession = MySession.Variables;

... though that looks kind of dirty to me at first glance. However, I don't know how much of a benefit using a list for storage actually gives to code/performance since storing an object that represents a list should take as much memory as doing each variable separately, at least that is my thinking.

---

Question

Which is better practice / low maintenance in the long-term? And/or Which gives better performance to the website?

Answer 1

Option #1 is the most common pattern that I see, and I use it. You can improve it by using constants instead of magic strings. Sessions have their issues, but so does making a completely stateless app. I also recommend using HttpCache instead of Session -- it will not consume AppPool resources. But only Sessions can be used on a web farm, as long as you use a Session provider like SQL Server. Distributed caching is another matter.

Answer 2

With option 1 it's really easy to tell what it's doing. You're trying to standardize how your classes save/retrieve session data rather than scattering it all over the place.

Option 2 is a lot more confusing. In fact I've looked it over a few times and I can't figure what's going on the list. Why does option 2 require a list when option 1 doesn't?

For what you're trying to do, option 1 works just fine. The constants aren't a bad idea, but in this one case I might skip it. The meaning of the string is pretty obvious, and other classes won't need to duplicate it because they're going through this one to access Session.

Answer 3

Option #1 > Option #2

Two reasons:

1. You should be deleting session variables as soon as you are done with them, using Session.Remove . Otherwise your session state will keep getting bigger and bigger and your web server won't be able to support as many simultaneous users. But if all your variables are held in one big session variable, this is a bit harder to accomplish.

2. I would avoid using reference types (eg a List of any kind) in session. It creates an ambiguity: if your session is stored in-proc, the session is only storing a pointer, and you can change session variables by changing the objects that they reference just like normal reference types. But if your session is out of proc (eg using state server or SQL state) then your objects will be serialized and frozen, and if you change the objects that are referenced, those changes will not get reflected in your session variables. This could create all sorts of bugs that only appear on your upper environments (if your dev systems lack a state server) and drive you mad trying to troubleshoot.

   You could possibly make an exception for immutable reference types, but you'd have to be careful; just because an object is immutable doesn't mean the objects that it references are immutable too.