Why a provider?

Jan 21, 2008 at 1:17 PM
Why have you created a caching provider rather than just a static class as the built in .NET caching doesnt seem to be overridable using providers?
Jan 22, 2008 at 4:17 PM
Provider model allows replacing the functionality without any code change as long as the interface remains the same. So if for some reason you want to make some customizations to code other code won’t be affected. Secondly the configuration is inside web.config for easy modification.
Jan 25, 2008 at 4:51 PM
Cache provider makes a lot of sense for consistency with ASP.NET provider model, but can be a pain in a tiered application. Accessing providers on the business or data tiers is not trivial, and assuming an ASP.NET context when writing/reading objects to cache on the data tier is not ideal.

I'd consider extending the Enterprise Library Caching Application Block, or using a container such as Castle.Windsor (that's what we did). Our implementation was super-easy, we just created an ICache interface with 3 implementations: Mockup (in-memory dictionary, used for unit tests), In-Memory (using the ASP.NET built-in cache) and Distributed (using memcached). Then it's just a matter of changing the castle configuration in app.config or web.config. Very similar to an ASP.NET provider, but not limited to web applications.