[SOS] Save Our State – Application Variables
Continuing what we were saying… So session doesn’t work for you and you need something that is:
- Variable shared by all users
- Saved in server memory
That is exactly what application variables is all about, one bucket for all users, variables are labeled inside it. Interestingly enough application come very close to:
- ASP.NET Caching – but what is very deferent is caching you can create dependency & time for expiration, additionally ASP.NET runtime controls memory allocated for cached object and remove the least accessed periodically.
- Static variables: now let us stop for a while here cause this one is pretty inter,
o static variables are inited when app domain is initiated (static ctors however is with first call to the class). App variables you control adding to them
o static variables are not thread safe, app vars provide lock/unlock method for thread safety purposes.
o Static variables are not shared across app domains/servers same applies for app vars.
o Static variables increases your server memory consumption so app vars, however you can write simple code to dump app vars and you get quick statistics on what is your application is doing. That you cannot do with static variables (or you can using reflection which is not something straight forward)
So when to use application variables and for what?
Use them when you want to share variables across classes, where this variable represents an application wide functionary (static variables are used to flag module wide functions). That is probably the most logical design decision
Next is view state...