You can virtually place your Cache access operations (read/write) wherever you have data, but in order to design modular and maintainable software it’s a good idea to centralize these operations into a separate layer to encapsulate and prevent ripple effect when changing the underlying provider (imagine that you start using Memcached, however your design should be good enough to allow a migration to somewhere like AppFabric Caching Service). Now the question is: where does exactly in my design fit the Cache layer?
The worst answer I can think of it’s replying with only one possibility. As a software Designer/Architect you should consider many scenarios and chose the best. Avoid facing your design decisions with a golden hammer / silver bullet. A common poor answer is placing the Cache layer between your Business and Data Layers. Another common answer is placing it between the Data Layer and the underlying data store.
The best thing to do is checking all the possibilities and assesses them according to your needs. In my experience I prefer caching in UI Components, UI Process Components, Data Access Components or in Service Agents because those scenarios offer performance improvements.
Another factor that can influence your decision is if you want caching fine-grained or coarse-grained data. I mean, you can opt between caching a plain query result or an UI-Entity collection ready to be consumed by the front-end.
Javier Andrés Cáceres AlvisMicrosoft Most Valuable Professional – MVP Intel Black Belt Software Developer