Software Mechanics
Why do we even have that lever?

Thinking about the future of the Caching block

December 15, 2009 08:36 by Chris

We’re hard at work on Enterprise Library 5.0. One of the things that we’re going to be digging into pretty heavily is .NET 4.0 compatibility. As part of that, I’m beginning to wonder (again) about which blocks still make sense in Entlib.

The Caching block is one of our more popular blocks. It’s been around since before Entlib 1.0 as a stand-alone piece. It was originally intended to suit the needs of occasionally connected client apps to have an offline, persistent cache of information from the server. In practice, it’s been used a lot as a simple in memory cache. We also get constant requests to build a distributed or shared cache.

Requests like this are what got me thinking. In .NET 2.0, the ASP.NET team did a ton of work to make System.Web.Cache work outside of web apps (sadly, they never updated their docs to say so). Since they’re at a lower level than we can write at, the web cache stuff makes a much, much better in memory cache than we can. It monitors overall memory usage, for example, while the best we can do is track how many items are in our cache. With the upcoming release of the cache-formerly-known-as-Velocity, Microsoft has a quality distributed cache technology available. We’d be nuts to try and replicate all that work. We did an analysis of the APIs between our CacheManager and the Velocity cache and came to the conclusion that wrapping Velocity in our interface would cost you a huge amount of capability, so we decided the best guidance was “use Velocity” rather than go through the caching block.

Finally, in .NET 4.0, there’s a new namespace called System.Runtime.Caching, which provides essentially the ASP.NET cache mechanism, but with a provider model behind it. So you can use the existing cache, but you could also plug in new implementations of caching as well.

So, here’s my thinking: given the presence of System.Runtime.Caching, does it make sense to have the caching block at all in Entlib 6? The only scenario that isn’t met by it is the persistent offline cache, and that can be done by building a new cache provider. We’ve always said that p&p’s job was to fill gaps in the platform until the platform catches up. In this case, the platform has definitely caught up, and even passed us in some ways.

Do you use the caching block? Does it do anything you couldn’t do as well or better through the framework provided mechanisms? Is it just backwards compatibility keeping you on it, or is there something I’m missing?

Let us know!

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories: Entlib | p&p | .NET
Actions: E-mail | Permalink | Comments (9) | Comment RSSRSS comment feed


Comments are closed