Question

Long time listener – first time caller. I am hoping to get some advice. I have been reading about caching in .net – both with System.Web.Caching and System.Runtime.Caching. I am wondering what additional benefits I can get vs simply creating a static variable with locking. My current (simple minded) caching method is like this:

public class Cache
{
    private static List<Category> _allCategories;
    private static readonly object _lockObject = new object();

    public static List<Category> AllCategories
    {
        get
        {
            lock (_lockObject)
            {
                if (_allCategories == null)
                {
                    _allCategories = //DB CALL TO POPULATE
                }
            }
            return _allCategories;
        }
    }
}

Other than expiration (and I wouldn’t want this to expire) I am at a loss to see what the benefit of using the built in caching are.

Maybe there are benefits for more complex caching scenarios that don’t apply to me – or maybe I am just missing something (would not be the first time).

So, what is the advantage of using cache if I want a cache that never expires? Doesn’t static variables do this?

Answer 1

First of all, Xaqron makes a good point that what you’re talking about probably doesn’t qualify as caching. It’s really just a lazily-loaded globally-accessible variable. That’s fine: as a practical programmer, there’s no point bending over backward to implement full-on caching where it’s not really beneficial. If you’re going to use this approach, though, you might as well be Lazy and let .NET 4 do the heavy lifting:

private static Lazy<IEnumerable<Category>> _allCategories
    = new Lazy<IEnumerable<Category>>(() => /* Db call to populate */);

public static IEnumerable<Category> AllCategories 
{ 
    get { return _allCategories.Value; } 
}

I took the liberty of changing the type to IEnumerable<Category> to prevent callers from thinking they can add to this list.

That said, any time you’re accessing a public static member, you’re missing out on a lot of flexibility that Object-Oriented Programming has to offer. I’d personally recommend that you:

1. Rename the class to CategoryRepository (or something like that),
2. Make this class implement an ICategoryRepository interface, with a GetAllCategories() method on the interface, and
3. Have this interface be constructor-injected into any classes that need it.

This approach will make it possible for you to unit test classes that are supposed to do things with all the categories, with full control over which "categories" are tested, and without the need for a database call.