the ‘bee log

I think Scott hits the nail on the head right here. Specifically that the Microsoft tools, guidance, and message (as of late) have been heavily centered on DataSet, DataReader and the like. I think these

I agree an Object Relational Mapper with LINQ as the Query Object implementation is very, very cool and certainly beats the heck out of NHibernate’s HQL, embedded database awareness in DDD repositories, or a roll-your own. The goal is to insulate and encapsulate the data layer and this is very, very hard to do with the current tools. I think LINQ is a double edge sword; if you’re using DLINQ to rip objects right off your database and these objects are sent directly to consumers, you’ve introduced fragility problems in your architecture. Changing a table’s structure amounts to changing all the features in the stack that have a dependency on the object (essentially defined by the table) from UI, Services, Business Components, etc.

So what do you need? A mapping layer. This is something an ORM like NHibernate (or what they’re proposing with the next ADO.NET) should give you out of the box.

That aside, for larger applications it’s time to break our entity representations out. Consider a medium-scale enterprise application that’s architect with a smart client, web services, and encapsulating business logic on the server in an object oriented Domain Model:

1. I want to use Domain Model on the server.
2. I want to persist my Domain Model objects into SQL Server tables. 
3. I want to serialize XML messages and use these messages as the basis for orchestrating activities on my Domain Model.
4. I want to write hardcore SQL in my business user facing reports.

Count ‘em — four separate paradigms for managing “entity data”. Four! But I want all of these things; they are what the situation/layer/architecture calls for. The ADO.NET vNext vision purports to solve this by managing a “conceptual model” through which different tools (object mapping, reporting, etc.) can work through to get a common representation… I’m just a bit skeptical.

For me (right now in the real world) it’s time to get past the “mobile data object” that travels from database to middle-tier to client, etc; It’s a holy grail. Instead, I’ll choose (where I can) to leverage the right paradigm for the right job in the right layer.  You have to look at every layer of your application and say, “when this entity leaves this layer in what format should it be in”. Different architectural layers work better with different entity formats: XML, Object, DataSet, etc.

How are you solving the problem of moving data across (potentially distributed) layers? Or - like me - have you given up?