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?

Before I get into this, let me say that the SOA discussion overall is increasing the ability to make better servers. And I think I could demonstrate that most of the benefits of SOA still apply to this, with the exceptions I mention below.

Let us assume that SOA is absolutely the best way to move data between servers and clients.

Let us assume that we want to write clients in an object-oriented system most or all of the time.

Will we then need a whole new class of tools to translate between raw message data and objects with behavior to build such clients? Consider the well-known impedance mismatch between object and relational data. Isn't this a very similar situation from the client's point of view?