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?

When building a distributed application, should you use a Thick Client or a Thin Client?

Rockford Lhotka explains, better than I could, another option. It's strongly influenced several of my posts, and if you find my n-tier concepts wacky, you need to read about Lhotka's Mobile Object model.

Short version: A way around many of the limitations of the thick or thin clients is to allow the objects to move freely between the middle tier and the client. Not the data. The objects.