After reading this post about LINQ, I think a few people are missing the point of LINQ... LINQ *replaces* any "Data Access layers" that have been created.
When you build methods in your data access layer, like "GetCustomersByCity," you're actually creating a wierd separation between the data and business layers. In a sense, you're defining business logic in your data layer. The important thing to remember, is that your business layer RELIES on the data layer to retrieve and persist entities so the business layer can process them.
LINQ's future
I see the future where LINQ augments our current Data Access layers and eventually most of the hand written code (call into very specificly created stored procedures for data optimization) will become obsolete.
Moving forward, a project would simply use SqlMetal (or any other code-gen engine for that matter) and build the Linq-supporting types into your current Data Access layer. Then, when you add new business logic components, and upgrade existing business logic code, add the newer LINQ-style access into the business layer.
Eventually, you'll find that most of the data access handling will be through the LINQ-execution engine, and less and less custom developed code.
Performance
Of course, there's always a case where a specific method is written to short-circuit some code path for maximum speed... Those particular instances may be better, but frankly, to quote ScottGu's post on LINQ: "LINQ is fast... very fast"
Some other articles about performance with LINQ:
- blogs.msdn.com/mattwar/archive/2007/07/05/linq-to-sql-rico-drops-the-other-shoe.aspx
More to come...