Why use System.Runtime.Caching or System.Web.Cachi

问题:

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?

回答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.

回答2:

System.Runtime.Caching and System.Web.Caching have automatic expiration control, that can be based on file-changes, SQL Server DB changes, and you can implement your own "changes provider". You can even create dependecies between cache entries.

See this link to know more about the System.Caching namespace:

http://msdn.microsoft.com/en-us/library/system.runtime.caching.aspx

All of the features I have mentioned are documented in the link.

Using static variables, would require manual control of expiration, and you would have to use file system watchers and others that are provided in the caching namespace.

回答3:

Other than expiration (and I wouldn't want this to expire) ...

If you don't care about the life-time the name is not caching anymore.

Still using Application (your case) and Session object are best practices for storing application level and session level data.