Rethink decision of deprecating caching block

Topics: Caching Application Block
Jul 29, 2010 at 6:45 AM


As I can see there are plans to remove the caching application block from the EntLib for the version 6.0 because there is the System.Runtime.Caching namespace in the .NET 4.0 Framework. I must say I do not understand this decision. I looked into the implementation of the System.Runtime.Caching namespace in the .NET Framework and the implementation is not as sophisticated as the caching application block. Stuff like interfaced based refresh actions, Isolated Storage, DatabaseStorage and BackgroundScheduler need to be reinvented. I hate reinventing the wheel. I think as long as the System.Runtime.Caching implementations are not on the same level as the caching application block it would be rather unwise to remove it!

What do you think?


Jul 29, 2010 at 8:19 AM

The reasoning is that caching, even if it isn't "as good", is now directly supported in the platform. Maintaining the caching block is a non-zero effort that competes with the other things we'd like to do with Enterprise Library. We're a very small team, especially compared to the team that built System.Runtime.Caching, and rather than duplicating effort we'd rather work on something new / different / value additive.

My current thinking is that we take our primary scenario for the caching block - offline persistent caching - and implement that as a provider under the System.Runtime.Caching system rather than having and maintaining our own interface and infrastructure, and provide guidance on how to move to the platform. For in-memory caching, the system one is a much better choice - it's plugged in at a much lower level and can actually scavenge based on memory usage, rather than just number of entries like we currently do.

The other big thing is user confusion - if we keep them both around, we have to spend a lot of time answering the "which one do we use?" question.

Now, having said that, nothing's been decided yet; we haven't even really started planning for V6. Thanks for expressing your opinion on this issue, and when we gear up for the next version please be sure to let us know!


Jul 29, 2010 at 9:33 AM

Thanks for the feedback. I think your current thinking would be a good approach.

Another point is that I found a blog post complaining about the current speed of the System.Runtime.Caching implementation compared to Caching Application block.

For me the decision which caching to use must be taken in the next few days. What I really like with the caching application block is the RefreshAction. This allows me to define refresh actions which dynamically retrieve data from remote sources (like webservices). Combined with smart IoC container the RefreshAction can be build up dynamically allowing to inject dependencies into it. This seems really good point for caching application block including the fact the RefreshActions are executed on seperate thread. Which I can't see in the System.Runtime.Caching implementation.