Best Solution for Caching

Question

Where is the best place to implement caching in a web based app?

• At the presentation layer (hope not)?
• At the Business Logic Layer?
• At the data layer?

I'm going to use something like memcached or MS Velocity under the hood.

I'm just finding myself writing so much code to update the cache here and there in the business logic layer, so would it be better to create a fabric in between the data access layer at the Database Server to cache data?

I think these complications are down to the fact, most of the data we are caching is user specific and we are duplicating data in the cache. We struggling to find the best solution.

Answer 1

Data Layer - all layers above this layer don't need to know where the data is sourced from. I would also only cache data thats not very volatile, or include some expiration policy.

Answer 2

I can't speak for ASP.NET specific stuff, but I've generally found that you can cache at each level. Your data tier will cache data responses, your presentation layer may find the need to cache generated presentation elements (e.g., user-specific style sheets), etc. In most cases, the data tier is the heaviest cache user and the other tiers will include an object cache if one is proven to be necessary.

The hardest part is getting cache invalidation working correctly. Stale caches are a major headache during deployment. Make sure to figure out how you are going to manage the lifetime of each cache object. LRU caches work well for caching static elements based on demand. Most data caches, however, will need an explicit life cycle whether it be based on an expiration timer or tied to some sort of a user session.

Answer 3

Data layer. But it is confusing because we use ASP.NET caching. With its expiration and dependency capability, it's pretty handy. So our business layer has no idea the data layer might be caching but the data layer uses a presentation-layer technology for caching! :(