CODEWITHSUNDEEP
asp.net
Clox
Clox

Reputation: 1943

Storing data in AppState and Session

In my AppStart.cshtml I fetch some data from the database, do calculations, serialize/deserialize json strings and such, etc, and I store the result in a couple AppState-variables by doing something like the following:(C#)

AppState["myVar1"]="aString";
AppState["myVar2"]=anArray;

These variables are accessed frequently and are a bit heavy to define so I thought something like this would make sense rather than creating the data from scratch every time it's needed. Even if the optimization isn't needed it still makes sense to me since it also increases readability and definitely maintainability by not having the same code in a bunch of places where that data is needed.

Likewise, I do similar actions on a per-user basis by putting data in Session whenver a user logs in, e.g.

Session["userVar1"]="myString";
Session["userVar2"]=myAray;

However, I've just read that we should never rely on that the data stored in these still exist when we want to read them because they're stored in the server-memory which might have been cleared. Is this true? So when we want to access one of these we should first check whether it's null or not? And if we're lucky it's not null and we can use it straight away, otherwise we set it again. Is this how data stored in AppState and Session are supposed to be used? And if so, what would be a good way of re-setting them if they're null? I suppose doing something like creating a function which sets them if they're null?

Upvotes: 0

Views: 440

Answers (1)

David
David

Reputation: 218827

In your case it sounds like it's fine if the data is occasionally cleared by the server (re-starting the app process from IIS, for example) because what you've described is just a caching scenario. Cache data is inherently transient. If it's there, use it. If it's not there, re-fetch it (and populate the cache again with the result).

What I would suggest is abstracting your cache mechanism (app state and session state) from the structure of the cache itself. And within this structure you can check if the data is cached and, if not, re-cache it. Consider an object like this:

public class CacheManager
{
    public static string MyString
    {
        get
        {
            if (string.IsNullOrWhiteSpace(AppState["myVar1"]))
            {
                // Fetch the value to be cached and set it in AppState["myVar1"]
            }
            return AppState["myVar1"];
        }
    }
}

Now anywhere in your application you can get the value by calling:

CacheManager.MyString

The rest of the application doesn't know or care if it's from app state, or session state, or a database, or a file, or any other transient location for cached data. That's entirely handled by the cache manager object. So if you ever want to change where certain values are located, you change them in that one place. Or if, for testing purposes, you want to remove the cache entirely and always get the data live, you'd just swap out the cache manager implementation with one that always returns re-fetched data. The rest of the application is blissfully unaware of the implementation.

Upvotes: 1

Related Questions