A custom variable that is user-specific

Question

I'm trying to wrap my head around this, but I just can't.

Let's say I have a class called custom. I have a variable in it called User_ID, which I use to retrieve a user's session (so I don't have to keep calling the session variable over and over again). Something like this:

Public Class custom

Public Shared User_ID as integer

Public Shared sub GatherUserID()

   User_ID = Session ("user_ID")

end sub

end class

Yes, it's a very simple example, but it gets my point across. I've done things similar to this in classic ASP (using includes, not classes) and the User_ID would be unique to whomever was accessing the page in question at that time.

For some reason, and this is what I don't understand, when I use custom.User_ID in a custom class, it's shared for everyone. That's what I don't want. What I want is to be able to use a variable like that and keep it user-specific. I see the advantage to sharing variables across classes (e.g. database connection strings), but I don't see how to set up a custom variable in a custom class that I can use just for that user without having to constantly call Sessions.

I see that I can declare it as a Property as opposed to a shared variable, but I really don't know what exactly that is intended to accomplish, and no one seems to have a clear explanation. Is a Property user/session-specific? Will it solve my specific problem as a result? This is what I don't get.

EDIT: just to clarify, the user_ID in this example is something I intend to use in several spots that get called during the creation of a page (e.g. the master file, the page itself, various classes.) Hence the reason for the creation of a custom variable.

Thanks.

Answer 1

Shared means it's shared with everyone in the app domain. When you call a method and it sets a shared variable, everything that uses the shared variable will get the same value returned.

What you can do is wrap your access to the Session object. Using either a Module, or my preferred method, using an Extension method and a shared custom class that I hang off of Session. This allows me to see that it comes from Session, but access it like Session.vars.UserID with UserID being a property of the vars class.

Module SessionExt

    Public Class SessionVars
        Private this as HttpSessionState
        Public New (ths as HttpSessionState)
            this = ths
        End New
        Public Property Example as Integer
            Get
               Static nm as String = MethodBase.GetCurrentMethod().Name.Substring(4)
               return CType(this(nm), Integer)
            End Get
            Set (value as Integer)
               Static nm as String = MethodBase.GetCurrentMethod().Name.Substring(4)
               this(nm) = value
            End Set
        End Property 
    End Class
    <Extension()>
    Public Function vars(ByVal this as HttpSessionState) as SessionVars
        return New SessionVars(this)
    End Function
End Module

And there you go, all of your session variables wrapped up in a nice class. Adding a new property is simple boiler plate code, all you have to do is change the name and set the type. You can refactor it to a better name, see where it is being used, use it to contain more complex structures (datatables, other classes or structures, etc).

NOTE: If you are using a global.asax, the session might not have been established yet when your code runs, be careful that that any property you call from there either doesn't use the session state, or it checks for null first.

Answer 2

Public Class custom

Public User_ID as integer

Public sub GatherUserID()

   User_ID = Session ("user_ID")

end Sub

end Class

Then, for each new user that starts a session:

Dim userSpecificCustom as New Custom()
userSpecificCustom.GatherUserID()

I'm a C# guy, so don't knock me down if the syntax isn't 100% correct.

It's also recommended to make User_ID a property rather than a public field. (see eg. http://www.vbdotnetheaven.com/uploadfile/manish1231/fields-and-properties-in-vb-net/ or http://blogs.msdn.com/b/vbteam/archive/2009/09/04/properties-vs-fields-why-does-it-matter-jonathan-aneja.aspx)