Passing Variables… 2

[M444]

It may seem that this topic has been covered extensively in Microsoft’s documentation, technical websites, and in previous tek-tip posts but no source, that I have found, fully addresses my real-world issues.

Basically I would like to know how you would handle passing variables in this situation? And why?

I have eight variables which I need to keep track of for each user… I currently use sessions to store them… but everything I read says this is cumbersome on the server… With each user requiring eight variables they add up quickly...

I would use the querystring to pass the variables, but the values need to be secure. I could encrypt the querystring… but that brings up usability issues.

The server transfer method, documented at

http://www.dotnetbips.com/Articles/displayarticle.aspx?id=79

looks promising… but I’m not sure this is the best answer…

Perhaps placing the value in cache with a unique value for each user would be best?
Something like:

Cache(Session(“User_ID”) & “ProjectID”) = txtProject_ID.text ‘assuming I keep User_ID stored using session

Response.write(cache(Session(“User_ID”) & “ProjectID”))

Oh yeah… cookies are out of the question...


How would you do this?
How do you do this?

http://msdn.microsoft.com/msdnmag/issues/03/04/ASPNETUserState/default.aspx

 

[SiriusBlackOp]

There is a way to store them in the VeiwState as well, but you wouldn't want to store anything huge in there as it will need to be downloaded and uploaded every time. Slows things down.

Personally, if the 8 values are kept to a small size I would use the session state.

You could also use SQL if you wanted to.

Good and Bad points to all of these methods. ;o)

Senior Software Developer

http://www.scoutsft.com

 

[tperri]

I've seen someone mention in another thread to use a struct and pass that struct with those values? I dont know what performance impact there would be as Ive never used this technique

 

[ca8msm]

It depends what you are storing, how large it will be, for how long, how often you need to access them and in what scope you need to access them. Without this information, no decent advice can be given to you.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[SiriusBlackOp]

Also... How many users (maximum) are you planing on serving at any given time, and what resources are availible for use on the server?

Senior Software Developer

http://www.scoutsft.com

 

[M444]

ca8msm,

"It depends what you are storing" Good point…

The circumstances I would like to know the best practices for are as follows:

1. User_ID - currently using session

Storing: User_ID (SECURE not easily manipulated or visible)
How large: Small
How Long: As long as user is active
Accessed: Every request unique to user

2. Selected_Project_ID – currently using session (this seems to be the best method)

Storing: Selected_Project_ID (A project that a user has selected to view information about – Do not want this to be manipulated easily by user)
How large: An Integer
How Long: Across 3-4 pages
Accessed: Once each time the user Accesses any of those 3-4 pages

3. Project_Name – Currently using querystring

Storing: Project_Name (A project Name – Just for display does not have to be secure)
How large: Text 1-50 characters
How Long: Across 3-4 pages
Accessed: Once each time the user Accesses any of those 3-4 pages

4. Current_Page – Currently using querystring mypage.aspx?page=CurrentPage (this is probably a horrible way to deal with this…)

Storing: Current_Page (used to display to the user their current page… also used, on some pages, to format controls based on page… would rather not allow user to manipulate)
How large: Text 10-30 characters
How Long: Current page/request
Accessed: Changes each page… MUST BE ABLE to access in the on_load event of user controls


The application will be used by 50 or so users… probably no more than 10-15 at a time, but should be fairly scalable.

 

[SiriusBlackOp]

I don's see anything all too horrible about how you are doing this, but one of my pet-peeves about Session Vars is that they can quickly become many, scattered, overused, and the next thing you know you can't remember what's going on.

What I try to do personally is to use no more than 3 session variables, and I only use them to store small amounts of data. Everything up above is perfectly reasonable and very small.

So, here is what I would do to clean this up.
> Create a new class called SessionData (or something)
> > Create public properties for the class for your data to be stored in.
> > Create a Sub New(UserID as string, and all other REQUIRED data for a new user login).
> Create a new page called something like AppGlobal.
> > Create a variable like: "Protected oSessionData as SessionData"
> > In the AppGlobal.PageLoad sub, look to see if the Session Var "MySessionData" is nothing, if not send them to the login screen, else set oSessionData = Session Var "MySessionData".
> Change all pages inheritance from "Inherits System.Web.UI.Page" to "Inherits AppGlobal" EXCEPT the login page.
> On login completion, create a NEW instance of SessionData (setting the required data) and Add it as Session Var "MySessionData"

At this point you can always access your user's data via the oSessionData object (which contains all of your properties from any page that inherits AppGlobal... AND all pages with that inheritance will also be auto-magically protected from a user trying to type in an address manually to reach it.

Basically: on any page you should be able to say something like "oSessionData.UserID" to return the string.

One more thing, on logout set the oSessionData = Nothing.


This may seem a little confusing... but once you get it setup it becomes very well organized and easy to program against... and more readable.


Senior Software Developer

http://www.scoutsft.com

 

[SiriusBlackOp]

Also... change this:

Create public properties for the class for your data to be stored in

TO:

Create Protected properties for the class for your data to be stored in


Senior Software Developer

http://www.scoutsft.com

 

[M444]

Thanks SirusBlackOp,

Your variable handling makes sense. Basically you manage all of the user’s session information through this inherited page and session class which you have explained… I like your concept; its nice and clean.

I’m going to try to implement this on a test app and see how it works.

Thanks,
C

 

[ca8msm]

That's a well thought out method and I can see some good advantages of it.

However, in this situation I think it's overkill. Assuming your have a fairly decent web server, storing 4 session variables (the greatest of which is a 150 character string) for 50 users, should have pretty much no impact on the server. In this case I would just use session variables in their native state.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[SiriusBlackOp]

Zactly M444! You got it.

One note though, you will only ever use the AppGlobal page's code behind class, and therefore you should be able to delete the aspx file. The only reason I started you out that way is that instead of a blank class is because VS.NET will create that class with the correct inheritance and the Page_Load sub already in place. ;o)

... and maybe it is overkill right now, but if this is a growing application then why not start this when it's smaller? just my 2 cents.

Thank you for the stars!

Senior Software Developer

http://www.scoutsft.com

 

[jshurst]

Just going to throw this in there (as I do in most posts about sessions ;-), if this is a growing application and you decide to implement load_balancing then you'll need to store these sessions at another level (i.e. database level), which is going to slow down overall performance of the application. However, if you aren't going to do this then there should be no problem.

 

[DotNetGnat]

SiriusBlackOp,

Why dont you come up with a FAQ on this topic.

thanks

-DNG