Change tracking, the ADO.NET Entity Framework and DataSets
Andres Aguiar started an interesting discussion about disconnected operation and change tracking in the ADO.NET Entity Framework.
Andres regrets that the Entity Framework doesn't provide change tracking information:
This basically means that if you plan to build a multi-tier application with ADO.NET Orcas in the middle tier, you will need to hack your own change tracking mechanism in the client, send the whole changeset, and apply it in the middle tier. From this point of view, it's a huge step backwards, as that's something we already have with DataSets today.
In a reply to Andres' post, Udi Dahan states that an application should not rely on change tracking information.
I believe that there are several kinds of applications and I don't think everybody must move to a unique kind of application.
Some application don't require change tracking, others do. I've worked on applications that require it and Andres describes very well how they work in a subsequent post. One additional advantage of having state information is that you can display a collection of items (often details in a master-details relationship) in a grid, with changed items in italic, new items in bold and deleted items with strike-through text.
I don't understand why an SOA architecture wouldn't allow an UpdateOrder kind of command, but if it's the case, then a lot of applications are not compatible with SOA. If the ADO.NET Entity Framework or other mapping frameworks do not provide change information, then I'd say that DataSets are here to stay for a while...
I don't think there can be only one architecture for all applications. Both approaches described by Andres and Udi should coexist. If the ADO.NET Entity Framework doesn't provide support for change tracking, then another tool is need for some applications. If the the Entity Framework is open enough, then maybe extensions to it can add the support for change tracking?