What options besides using $_SESSION

Question

I am working on a .net project that relies on pulling some information from a database upon login and persisting the information while the person is logged in.

The site is complex, but I feel that overuse of the Session variable may be occurring. I will right now say that I'm using session to store about 5 int values and 3 or 4 string values. I don't have any complex objects stored in it. Every page of my site utilizes these values multiple times, and I feel that posting them each time would be ridiculous. I don't think that viewstate is any better than session at this point either, but i'm open to suggestions.

Example current usage of Session variable

this.Session["vendorCategoryId"]
this.Session["ftp_directory_name"]
this.Session["VendorCodeOptionRefId"]

I thought about implementing a struct in a class and having a set method there that I use from Global.asax.cs in the Session_Start() event might be one solution...

(EDIT: This solution is designed to avoid having to hammer the db every time any piece of code wants to access the variables).

In VendorSessionData.cs class

    public struct VendorData
    {
        public int VendorCategoryId;

        public int NKIAccountingCode;

        public int OptionCodeRefId;

        public string FtpDirName;
    }


    /// <summary>
    ///   The set vendor session data.
    /// </summary>
    public class VendorSessionData
    {
        #region Public Methods

        public static VendorData GetVendorData(Guid vendorGuid)
        {
            VendorData retVal = new VendorData();

            using (NKIDBDataContext db = new NKIDBDataContext())
            {

                vendorInfo vendorRefs = (from vendorInfo in db.vendorInfos where vendorInfo.guid == vendorGuid.ToString() select vendorInfo).SingleOrDefault();
                if (vendorRefs != null)
                {
                    retVal.VendorCategoryId = vendorRefs.category_id;
                    retVal.NKIAccountingCode = vendorRefs.nki_vendor_id;
                    retVal.OptionCodeRefId = vendorRefs.option_ref_id;
                    retVal.FtpDirName = vendorRefs.ftp_directory_name;
                }

            }

            return retVal;
        } ......

And in global.asax.cs

 public class Global : HttpApplication
        {

            public static VendorData CurrentVendorData;

            public void Session_Start(object sender, EventArgs e)
            {
/////////////////FYI tmpVendorGuid is set in code above this point
                 Guid tmpVendorGuid;
                 if (Guid.TryParse(vendorGuid, out tmpVendorGuid))
                 {
                     CurrentVendorData = VendorSessionData.GetVendorData(tmpVendorGuid);
                 }

Would it be better to try to attack this using hidden fields on the master page? Every search I've done says "don't use session, don't use globals.." basically any idea I have, there is some page stating its the worst idea ever :)

Any suggestions would be appreciated.

score 2 · Accepted Answer · answered Feb 25 '13 at 21:42

The amount of data isn't particularly surprising, but the choice is.

Normally a session would store user information (typically just their ID - you fetch the rest from the DB). "ftp_directory_name" sounds like a config variable or a per-user setting.

I'm surprised you don't store VendorData in the database with a unique ID and then just fetch the details (you'd need to store the Vendor ID in the session - if that's not the same as the User).

This solution is designed to avoid having to hammer the db every time any piece of code wants to access the variables

This seems like it might be a solution to a problem that doesn't exist - are you seeing problems with access time and are you sure this is the right solution? You're going to have to hit the DB for most pages anyway. One extra query per page load is unlikely to be a problem.

Yes, I'll agree its probably a solution to a problem that doesn't exist at this point. Its still nice to hear good solutions and suggestions. — CarComp, Feb 26 '13 at 20:46

score 1 · Answer 2 · answered Feb 25 '13 at 21:48

I'd say you're probably already doing it right... Session was designed for storing information for the user's "session"... I don't think you're taxing it too much as if you were storing an entire DataSet or something... A few int variables and a string take up less than 1K of memory... If you had 1,000 users logged in at the same time, their collective "Session" footprint would still be about 1MB... pitons on today's servers.

What options besides using $_SESSION

2 Answers2