Why use System.Runtime.Caching or System.Web.Caching Vs static variables?

by

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.

Leave a Comment