I\'m coming from the LAMP world, where the \"cache everything\" mentality is prevalent. Everything is put in memcache.
I\'m starting a new project with ASP.NET MVC and
dswatik provided a great link on how to use it.
I'd suggest adding this functionality somewhere in your Repository/Service layer to take the burden off of the application and to stay within the DRY principle.
The selected answer is for the Velocity CTP1. Here is the MSDN link for the latest Velocity Programming Guide.
As to your other question about design decisions, Chad Moran's suggestion to put the onus on the repository layer is great. Then, I would look at adding support for linq caching using a technique similar to the one described here: http://petemontgomery.wordpress.com/2008/08/07/caching-the-results-of-linq-queries/
You would obviously have to write an implementation that uses Velocity instead of the ASP.NET Cache ... but really, unless you have statistics to prove that you need something like Velocity, you can probably stick with the regular cache until it becomes a problem. If you listen to some of the talks that Joel Spolsky has given regarding stackoverflow, you'll find that two boxes (one with iis, and the other with sql server) can handle a very high volume.
Stephen Walther has a great article on how to do this
ASP.NET MVC Tip #39 – Use the Velocity Distributed Cache
@dswatic: Many thanks. It looks like I can add caching later on with minimal pain. Here's an important warning from that site though:
"If you use the Object Relational Designer to generate your LINQ to SQL classes then your LINQ to SQL classes will not be serializable. To work around this problem, I built my LINQ to SQL classes by hand."
Only serializable objects can be cached with Velocity.
Thanks again.