Proper method to grab session variable?

[Darrel]

I've created a class with a function that grabs/sets a session variable:

Public Class myClass
Shared Function myFunction()
return HttpContext.Current.Session("myVariable")
end function
end class

Is there anything wrong with that? Specifically, am I guaranteed that that
session only belongs to the person viewing the site?

In the past I've ran into issues setting/reading cookies from a shared
function like this when multiple people hit the application at the same
time. What was happening is that it was grabbing other's cookies if the
request managed to overlap.

-Darrel

 

[Cowboy \(Gregory A. Beamer\)]

Do you want to tightly couple your application to the library this class
sits in? If not, pulling session directly in the class is a bad thing. It
also makes the library not reusable. You are better, in most cases, to pull
session in the web application and feed to the library.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

*************************************************
| Think outside the box!
|
*************************************************

 

[darrel]

Do you want to tightly couple your application to the library this class

sits in? If not, pulling session directly in the class is a bad thing. It
also makes the library not reusable. You are better, in most cases, to
pull session in the web application and feed to the library.

So...I should check/grab sessionon the ASPX page itself, then pass whatever
on to the library class?

I assume by not doing that, I am running into that problem I had before,
where different users' 'paths' can get crossed and return someone else's
session variable?

-Darrel

 

[Cowboy \(Gregory A. Beamer\)]

So...I should check/grab sessionon the ASPX page itself, then pass
whatever on to the library class?

I would. The main reason is your libraries are then available to other forms
of applications. That may not be a concern today, but one day you might want
to use Silverlight or even a desktop WPF application. If you design the
library where the information is passed to it, it is still available for the
new methodology without recoding it.

I assume by not doing that, I am running into that problem I had before,
where different users' 'paths' can get crossed and return someone else's
session variable?

It is not as much a problem of getting the wrong value as intimately linking
two pieces that do not have to be intimately linked. I think of classes as
black boxes. If you can get info in the middle of the black box from the
calling application, you are, in effect, creating an inferred method call.
This is harder to maintain and forces every application using this library
to use the same session variable names. In addition, as mentioned above, you
cannot use this with any application that does not use a web session, as
currently envisioned. Any change in the session model in IIS will break the
application. It will probably not be your problem by that time, but it will
be a booger to debug, as you are not feeding the value, you are magically
pulling it out of thin air.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

*************************************************
| Think outside the box!
|
*************************************************

 

[darrel]

It is not as much a problem of getting the wrong value as intimately

linking two pieces that do not have to be intimately linked. I think of
classes as black boxes.

I see what you're saying. You're just giving me good OOP advice! ;o)

In this case, I'm trying to offload it all to a class as I want the front
end ASPX to be as simple/clean as possible for the end-users who are
modifying the HTML.

By moving the whole thing into the class library, I can distill the
front-end to a single dim statement:

dim myVariable as string = myClass.myFunction()

the goal isn't really reusable code as much as 'how to hide the vb from the
end-users who only know HTML'

in the past, I've had issues with using a class to grab cookies:

person 1 -> call class to get cookie variable and return it
person 2 -> call class to get cookie variable and return it

The problem would be if they BOTH hit the site at the same time, person 1
might get person's 2 cookie back.

I was wondering if that's an issue with sessions, or if, by default, they
are absolutely locked to invididual users.

-Darrel