views:

212

answers:

1

Here's the situation I have: I'm building an online system to be used by school groups. Only one school can log into the system at any one time, and from that school you'll get about 13 users. They then proceed into a educational application in which they have to co-operate to complete tasks, and from a code point of view, sharing variables all over the place.

I was thinking, if I set up a static class with static properties that hold the variables that are required to be shared, this could save me having to store/access the variables in/from a database, as long as the static variables are all properly initialized when the application starts and cleaned up at the end. Of course I would also have to put locks on the get and set methods to make the variables thread safe.

Something in the back of my mind is telling me this might be a terrible way of going about things, but I'm not sure exactly why, so if people could give me their thoughts for or against using a static class in this situation, I would be quite appreciative.

+3  A: 

If you want to share variables globally on your website you should use the Application State (System.Web.HttpApplicationState) that is available in any asp page with the variable named "Application".

It works just like the Session variable, storing values in a hashtable. The only thing is you'll have to manage locking for it to be thread-safe but if I remember well there are built-in methods or properties to lock and unlock variables.

Read more there : http://msdn.microsoft.com/en-us/library/ms178594(v=VS.100).aspx

StevenGilligan
Session is no good if the users are using individual logins.
drachenstern
Maybe I should explain myself more : I didn't say anything about using Sessions. I know Sessions are per-user, I was just saying that the Application object works the same. Just as you do Session["Key"] = value; to store something in the session you do Application["Key"] = value; The difference is that the Application object is global for the website so any value inserted in it from a user can be read and modified from any other user. You also have to do Application.Lock(); and Application.Unlock(); before manipulating it.
StevenGilligan
Yeah, but if he's refusing to use the database, then it's entirely possible he would try and use Sessions. Just thought I would point it out.
drachenstern
I knew I couldn't use sessions for this reason, but I'm giving the application state a go. I never really knew about it before, and it seems to be ideal for the situation at hand. Thanks.
death_au