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?
