C# – Static fields vs Session variables

asp.netcnetsession-variablesstatic-members

So far I've been using Session to pass some variables from one page to another. For instance user role. When a user logs in to the web application the role id of the user is kept in Session and that role is checked at different parts of the application. I've recently started thinking why not use static members instead. I can store the same information in a static field and easily access it anywhere in my application (well anywhere the namespace in which that static field resides is included.) I know that using Session variables comes handy sometimes, such that:

Any kind of data can be stored in Session. It then must be casted however.But static fields accept data with the correct datatype only.
Session variables will expire after a certain time which is the behavior we need in many cases.

Apart from the above, are there any other reasons why I should not use static fields to store data and have it available everywhere?

Best Answer

No, using static variables for this is not the way to go:

If your AppDomain is recycled, all your static variables will be "reset"
Static variables don't scale horizontally - if you load-balance your application, a user who hits one server then a different one won't see the data store in the static variables in the first server
Most importantly, static variables will be shared by all access to that server... it won't be on a per-user basis at all... whereas from your description, you wouldn't want user X to see user Y's information.

Fundamentally, you have two choices for propagating information around your application:

Keep it client-side, so each request gives the information from the previous steps. (This can become unwieldy with large amounts of information, but can be useful for simple cases.)
Keep it server-side, ideally in some persistent way (such as a database) with the client providing a session identifier.

If you can use load-balancing to keep all users going to the same server, and if you don't mind sessions being lost when the AppDomain is recycled¹ or a server going down, you can keep it in memory, keyed by session ID... but be careful.

¹ There may be mechanisms in ASP.NET to survive this, propagating session information from one AppDomain to another - I'm not sure

Related Solutions

C++ – How to initialize private static members in C++

The class declaration should be in the header file (Or in the source file if not shared).
File: foo.h

class foo
{
    private:
        static int i;
};

But the initialization should be in source file.
File: foo.cpp

int foo::i = 0;

If the initialization is in the header file then each file that includes the header file will have a definition of the static member. Thus during the link phase you will get linker errors as the code to initialize the variable will be defined in multiple source files. The initialisation of the static int i must be done outside of any function.

Note: Matt Curtis: points out that C++ allows the simplification of the above if the static member variable is of const int type (e.g. int, bool, char). You can then declare and initialize the member variable directly inside the class declaration in the header file:

class foo
{
    private:
        static int const i = 42;
};

C# – ‘Static readonly’ vs. ‘const’

public static readonly fields are a little unusual; public static properties (with only a get) would be more common (perhaps backed by a private static readonly field).

const values are burned directly into the call-site; this is double edged:

it is useless if the value is fetched at runtime, perhaps from config
if you change the value of a const, you need to rebuild all the clients
but it can be faster, as it avoids a method call...
...which might sometimes have been inlined by the JIT anyway

If the value will never change, then const is fine - Zero etc make reasonable consts ;p Other than that, static properties are more common.

Best Answer

Related Solutions

C++ – How to initialize private static members in C++

C# – ‘Static readonly’ vs. ‘const’

Related Topic