AppFabric vs System.Runtime.Caching

Question

TLDR version: For caching many small database tables that rarely change in my .NET4 WCF service. Which technology will be easiest to implement, easiest to maintain, and best to perform and why?

Long version: I'm starting to work on a caching strategy for a new project. It used to be simple because there were fewer pre-packaged options (Enterprise Library for starters), but now with the .NET 4 framework and AppFabric being available, I'm having a harder time deciding on a solution. Basically, I want to cache a multitude of small (<100 rows with 2-4 columns) database tables that rarely change and have my WCF service pull it from cache rather than pulling everytime from the database. I've begun reading the documentation, watching the videos, and downloading the training material, but experience is a better teacher and I've had a hard time finding comparisons between these two.

Any advice would be quite appreciated! Thanks!

Jews

Answer 1

to my understanding AppFabric is a distributed highly available inter-application caching platform.

compared to classic ASP.NET caching or other local caching systems, it does imply IPC which is slower than in-process caching and in-process calls anyway but has the big advantage that multiple applications can access the same cache cluster if needed and that restarting the app pool in IIS or the whole web server(s) won't imply losing the cache in case you have designed specific cache servers in your infrastructure.

being high-available and clustered if a cache server fails the other one(s) will still server the requests.

with local-cache enabled clients can still cache data also locally but once they fall or local cache is invalidated data will be retrieved from cache cluster and not directly from database, unless really needed.

I think there is a tradeoff, to decide if better to have IPC calls a bit slower but reliability and shared cache cluster in the company or not.

Pullulate