asp.net session vs. local variables in subs or functions - best practice

[The Colonel]

In a .vb class function, can I assign user-specific information (e.g.
First Name, Role, etc.) to local variables (as opposed to referring to
the session variable multiple times)?

 

[sloan]

You can define a small object, to encapsulate that data.

class User
string FName
string LName
string SSN

and then put that object into the Session.

OR
you can write a method to SessionCache the object.

class CacheFunctions
static void CacheUser (User u)
// session logic here.
static User GetCachedUser()
//get the item from the Session ...


OR
You can define the User class and use this nice wrapper object I wrote:
http://spaces.msn.com/sholliday/ 10/24/2005 entry

 

[Bob Barrows [MVP]]

In a .vb class function, can I assign user-specific information (e.g.
First Name, Role, etc.) to local variables (as opposed to referring to
the session variable multiple times)?

Yes, that would a be Best Practice. Using local variables avoids the
overhead of multiple accesses of the session object as well as the type
conversions involved. I've started following this pattern in my classes:

....
private _cachedobject as some_object
private/public/protected CachedObject() as some_object
Get
if _cachedobject is nothing then
'retrieve the object from cache/session/application
'and set the retrieved object to _cachedobject
'assuming session:
if not Session("CachedObject") is nothing then
_cachedobject=ctype(Session("CachedObject"), _
some_object)
end if
end if
return _cachedobject
End Get
Set (ByVal Value as some_object)
_cachedobject=value
'add Value to cache/session/application
End Set
End Property
....
public function MyFunction() as something
dim obj as some_object = Me.CachedObject
...
end function

 

[Guest]

Why not? Have you tried it? Provided the instance of whatever class is still
alive, and depending on the access modifiers on the "local variables" (e.g.
Public, etc)
that's a good idea. In the big scheme of things, if the Session objects
aren't too complex, it probably wouldn't make much difference.
Peter

 

[The Colonel]

I don't know - I guess I was afraid that once it's not a session
variable any more, that value would change for ALL concurrent app
users.

 

[Bob Barrows [MVP]]

Then I guess you don't truly understand what a session variable is. A
session variable has scope only for the user whose session created and
stored it. See if this helps:
http://msdn.microsoft.com/library/en-us/iissdk/html/050e0924-fd83-45e7-b105-50710538d6c1.asp

 

[Hans Kesting]

I don't know - I guess I was afraid that once it's not a session

variable any more, that value would change for ALL concurrent app
users.

Don't worry, other request work on different *instances* of that page,
so instance-variables are valid for this particular request only.
Only when you use *static* variables you will have these problems.

Hans Kesting