ASP.NET Hosting

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?
 

3 Comments

  • > If the the Entity Framework is open enough, then maybe extensions to it can add the support for change tracking?

    I highly doubt it.
    And I speak here as both someone who deals with OR/M and someone that deals with MS products.

    Other techniques exists for this to work property, from CLSA multi level undo to simply pulling a new instance from the DB and comparing against that.

    The UI effect that you describe is something that is almost always completely done in the UI layer, and it doesn't really require anything from the entity layer itself.

  • As pointed out by Frans Bouma in his blog, change tracking needs to be part of the entity objects - be it entities in LINQ to SQL or LINQ to Entities.

    The whole idea of disconnecting a list of entities from the central context, making changes and bringing those entities back for persistence relies on a local change tracking mechanism.

    Reading up entities from the datastore for comparing original values is not an option as (one or more of) the entities may have been deleted.

    I'm really hoping that the LINQ teams are listening to the feedback the receive around the net. Respected developers of ORMs (as well as other architects) have provided feedback on the missing feature to the team.

    Let's hope they change the scope for those technologies before v1.0.

  • Frans' post: http://weblogs.asp.net/fbouma/archive/2007/04/03/why-change-tracking-has-to-be-part-of-an-entity-object.aspx

Comments have been disabled for this content.