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

  • Thread starter Thread starter The Colonel
  • Start date Start date
T

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)?
 
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
 
The said:
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)?
Click to expand...

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
 
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
 
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.
 
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.
Click to expand...

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
 
Back
Top