Thread: Caching
View Single Post
  #6 (permalink)  
Old May 31st, 2010, 04:00 AM
Imar's Avatar
Imar Imar is offline
Wrox Author
Points: 72,038, Level: 100
Points: 72,038, Level: 100 Points: 72,038, Level: 100 Points: 72,038, Level: 100
Activity: 100%
Activity: 100% Activity: 100% Activity: 100%
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 17,080
Thanks: 80
Thanked 1,587 Times in 1,563 Posts

Yes, that pretty much summarizes it. A few remarks though:

I don't see static fields or properties as a cache, although they could fulfill that purpose. I mainly use them for simple fields such as configuration. For example:

public class AppConfiguration
  public static string FromAddress
      string result = WebConfigurationManager.AppSettings.Get("FromAddress");
      if (!string.IsNullOrEmpty(result))
        return result;
      throw new Exception("AppSetting FromAddress not found in web.config file.");
This static property can now be called as:

myMessage.From = new MailAddress(AppConfiguration.FromAddress);

Note that inside the getter you could "cache" the return value of WebConfigurationManager.AppSettings.Get in yet another static, and private field to avoid the overhead of accessing the configuration more than once. However, AFAIK, the WebConfigurationManager already minimizes the overhead.

So, the static field serves as a wrapper around the real data, in this example data stored in the web.config file.

The Cache, on the other hand, doesn't act as a wrapper, but serves as an alternative. The real data is copied (for example, the result of a DB query) and stored in the cache for quicker access. The benefits are quick access, at the cost of memory consumption and the risk of stale data.

Hope this helps,

Imar Spaanjaars
Follow me on Twitter

Author of Beginning ASP.NET 4.5 : in C# and VB, Beginning ASP.NET Web Pages with WebMatrix
and Beginning ASP.NET 4 : in C# and VB.
Did this post help you? Click the button below this post to show your appreciation!