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 SQL Server. I'll probably go with LINQ to SQL or maybe Entity Framework. Are there design decisions I need to make now for caching, or is it easy enough to start using Velocity if that becomes necessary? Just to be clear, I'm talking about Microsoft's Velocity cache and not the Apache Velocity template engine.
I'm hoping that I can ignore caching for the moment, because learning C#, ASP.NET MVC, LINQ, IIS, SQL Server, and becoming proficient in VS is keeping my plate full.
Stephen Walther has a great article on how to do this
ASP.NET MVC Tip #39 – Use the Velocity Distributed Cache
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.
@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.
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.
