views:

811

answers:

2

I have a question regarding Caching. I have a typical n-tier ASP.NET web app. I have made a custom Cache wrapper (wrapping ASP.NET Cache object), and I would like to know the best practices of Caching data. I don't want to use caching in my business layer (don't want to add any reference to System.Web dll there). Same case with DAL. So the only options left are:

  1. Cache everything in the UI layer
  2. Create a cache layer between UI and BL (dont know how feasible is that?)

I also heard about the upcoming Velocity caching framework but I guess that might be an overkill (as my app wont need a web farm/cluster).

I may be terribly wrong in my approaches, so I would welcome any suggestions or alternative approaches on how to effiecintly cache data in my web projects.

+7  A: 

The layer between your UI and BLL would be a Services layer, which is a good place for caching. Use an abstracted cache manager (example on my blog) so you can swap out providers (ASP.NET cache, Velocity, memcached, whatever) when needed.

John Sheehan
I like the example on your blog, great use of interfaces.
Rutger
We did the same thing and have actually done the migration from ASP.Net cache to memcache. How the Cache layer in ASP.Net is NOT natively pluggable is a mystery to me.
jro
It will be in ASP.NET 4
John Sheehan
+1  A: 

Sometimes it's also worth considering what the purpose of the cached data is for? If it's ultimately just going to generate static HTML in the UI layer than wrapping these parts in a user control and adding an @OutputCache directive can be the most efficient way (when using web forms, at least). It's easy to forget this, sometimes, when you get bogged down in caching frameworks etc. Of course I appreciate this may not be suitable or best-practise in many cases.

Dan Diplo
I basically want to cache data coming from the DB (or in short cache my business objects/collections).
Raghav Khunger