Scalability became of interest to developers with the advent of the web and heavy server-side web applications. I'm not straying far from the truth when I say that scalability and the advent of ASP.NET development are related. One tool developers have to satisfy the need for scalability is caching. Caching in ASP.NET is provided by a very powerful object—the Cache object. The Cache object provides dictionary-based data entry, data scavenging, notification, removal callbacks, and rich policies for expiring items. But it has one huge limitation—it doesn’t work very well in web farms. More precisely, it works but every machine ends up with its own copy of the data with no guarantee of synchronization. You can certainly do some work to achieve the minimum level of synchronization you need, but in the end you’re left alone with it.
The bottom line is that the Cache object is powerful but inherently limited to a single process. What if you need to use it in a web farm or you need to scale the caching tier across a cluster of machines? In both cases, the Cache object isn’t for you. You can switch to AppFabric Caching Services, which is the Microsoft version of a distributed cache, or you can use another API such as memcached, sharedmem, or commercial products.
Whichever way you look at it, you need to address a fundamental point. Are you going to stick to the same caching solution or is your code the kind that might support different caches in different scenarios? Also, are you going to test your cache-enabled code extensively? To properly address these points, you need to stop using the cache directly—whether it's the native Cache object, the new MemoryCache object in the .NET Framework 4, or a third-party cache. For extensibility and testability reasons, the caching layer in your ASP.NET (and ASP.NET MVC) applications should be based on a provider model or be IoC-enabled. Let’s see how to proceed.