Session vars vs. HttpContext.Current.User

  • Thread starter Thread starter Jason
  • Start date Start date
J

Jason

Currently, I am storing information about the currently logged on user
in Session variables that are stored in SQL. However, I am using
role-based security, so I am storing custom roles in a GenericPrincipal
object that I attached to Context.User. My question is this:

Can I create a new class, ExtendedPrincipal for instance, and simply
inherit System.Security.Principal and store all of the information
currently stored in Session variables in this new object? Is this
responsible/efficient/appropriate?

Thanks in advance!
Jason
 
Since the Session is specific to the User, there is no need to add this
level of complexity.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
 
Thanks. I was under the impression that using session variables was
yesterdays technology and that this information was handled better by a
new .NET way. This is good though. Now I don't have to go back and
make alot of changes.
 
Something you could do though would be to create a class with shared numbers
that exposes these session variables as properties.
This way you'll get strong typing and intellisense on those values plus you
don't need to change at once as under the hood there are still stored as
session variables.

Patrice
 
Never thought about that! But I am unfamiliar with "shared numbers" or
how to get a list of "choices" to be displayed when you are trying to
set a property of a class.
 
What language are you using ? The keyword is Shared in VB.NET and static in
C#.
It allows to have a member that is the same for all objects of a class.
Under the hood it uses the user session to store the value.

Having a list is done using an Enumeration (Enum in both languages if I
remember)...

Actually I didn't thought about that either. Saw this suggestion once in
this group...

Patrice
 
Under the hood it uses the user session to store the value.

Static objects are stored in the application heap, not Session.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
 
No they aren't! They're stored as application variables.

Afraid not. Static objects are stored in the application heap. Always have
been. Always will be. That is, after all, the definition of "static."

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
 
Kevin ...
Technically, you are correct ... if these static members are merely
accessors for private variables. For example:
Public Class MySessionVars
Private Shared _myInt As Integer
Public Shared Property MyInt() As Integer
Get
Return _myInt
End Get
Set(ByVal Value As Integer)
_myInt = Value
End Set
End Property
End ClassThis would store the variables in the heap *and* have the same
values for every user! Not desirable in this situation.
Doing this, however, would be different:
Public Class MySessionVars
Public Shared Property MyInt() As Integer
Get
Return CInt(HttpContext.Current.Session("MyInt"))
End Get
Set(ByVal Value As Integer)
HttpContext.Current.Session("MyInt") = Value
End Set
End Property
End Class
In this case, the static property is merely a wrapper around the current
HttpContext's Session object. Note that this will *crash and burn* if not in
an ASP.NET environment! It is the second method that I think Patrice was
referring to ... and I would agree with Patrice on this practice. It's a
nice layer to abstract the details of the Session, providing flexibility on
storage location of the information, providing intellisense and strong
typing. Many Good Things(tm).
Jason ... you'd add the above class (or something like it) to your project
as a class file in the web solution. From there, you would refer to it like
so:
Dim myInt as Integer = MySessionVars.MyInt

You do not have to create an instance of the class to access static/Shared
members of the type.
 
Thanks to everyone for your input. My project is in C#, but the above
code is easily translatable. Once of these days, when I have nothing
better to do, I'm going to write a VB.NET -> C# -> VB.NET translator.
Then I'll be rich (provided someone else hasn't already done it).
 
Afraid not. Static objects are stored in the application heap. Always have
been. Always will be. That is, after all, the definition of "static."
Click to expand...

Isn't that what I said?
 
Around here, static is what you get when
people post unresearched "answers" to questions.

No signal. Just noisy static.

;-)



Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
 
Hi J,

Technically I AM correct. A Property is a wrapper for 2 (up to) methods (get
and set). If the Property is static, the methods are static, and stored in
the heap. A static method can work with Session and Application via the
HttpContext. However, the variables that it works with are NOT static.
Therefore, a static property is NOT stored in Session or Application, but in
the heap.

I wasn't disagreeing with Patrice's advice, simply pointing out a technical
error in her explanation of it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
 
Isn't that what I said?

No. It is not. Application variables are stored in an instantiated
Collection object in Application memory. Static objects are stored in the
heap. You do know what the heap is, don't you?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
 
You are both right !!

The "it" wasn't referring to static members in general but to the session
wrapper class that uses static properties and that stores under the hood the
value in the user session object as described by J Sawyer but I agree that I
was far from being clear...

Terminology is really sometimes difficult Kevin, properties are never
stored, they are just code that eventually stores something where you want
(not necessarily on the heap) ;-)

Patrice

--
 
Back
Top