Microsoft is talking a lot about its forthcoming LinQ for SQL (not DLinQ!) and ADO.NET Entity Framework technology and it really looks pretty sharp. (Despite the confusion over there being two mapping technologies.)

But I have a reservation. Here's a quote from the Entity Framework doc:

No plumbing. The code is very database intensive, yet there are no database connection objects, no external language such as SQL for query formulation, no parameter binding, no configuration embedded in code. In this sense, you could say this code is “pure business logic”.

(No time to grab an image just now. Go to the doc to see the code it's talking about, but if you've seen DLinQ samples before, you've seen it.)

So, is that a good thing? Pure business logic that generates the appropriate SQL and parameter binding and config logic? Or is that an unfortunate merging of domain concerns with implementation concerns?