@Jasmine: I don't think that LINQ or EF promote lazy database design at all! In fact, having a poorly designed database will probably cause more problems with these ORMs than if you were using straight SQL. Either way, your database should use primary keys, foreign keys, indexes, etc. The benfits of the ORMs is that you don't have to write the rudimentary database access code, and get to use LINQ queries right away. Could you elaborate on how they promote lazy design?

Oh yeah, you just need to make sure that the compiled query is being "cached". So you need to store it in an application-wide location so it doesn't get compiled every time.

@Jasmine: Your statement is somewhat confusing, so let me be as clear as I can. Compiled queries are ALWAYS faster. In an ASP.NET Application, when do you use a query JUST ONCE? Never! That query is used by thousands of different requests! So the usage scenario of using a query "just once" never occurs. I hope I am explaining myself better. As for this whole thing being a micro optimization, that might be true... but I still think the "performance tests" from Jeff and Rico are highly misleading.

I have analyzed this a lot and I think YOU ARE WRONG!!!!! (I apologize if I am way off on this, but...) Think about it. Provided that you are caching the compiled queries at an Application level, you are NEVER running the query JUST ONCE!!! If you store it at an Application level, it is being run for every single user, every time they hit that page!!! You DON'T create a new compiled query every page load and use it once. You compile it at application start up or when it is first used, and then used that compiled query in EVERY SINGLE CALL TO THE DAL! Am I right?