BT

No Change Tracking for ADO.NET Entity Framework 2010

| by Jonathan Allen Follow 639 Followers on Nov 24, 2008. Estimated reading time: 4 minutes |

One of the biggest complaints about ADO.NET Entity Framework, and LINQ to SQL, was that it did not support change tracking. You can change objects and save them back to the database, but only if you are connected to a context object. Once the context object goes out of scope, which like a database connection should be very quickly, the data objects essentially become read-only. There simply is not a good way to reattach them to a new context to write back their changes.

Microsoft's refusal to address this is downright puzzling. Instead of adding change tracking inside the data object, as most ORM libraries do, they are instead focusing more on POCO or "Plain Old C# Objects".

In the Entity Framework Design blog, three developers at Microsoft walk through some of the popular database access methods. First up is the ADO.NET DataSet, which is quite capable of writing back change sets to databases. They list four "problems" with the ADO.NET DataSet, none of which make much sense. They are all focused with sending change sets across untrusted boundaries, which doesn't make a whole lot of sense. Database access and ORM libraries are meant to sanitize data, that should be handled by the application itself.

Next up are DTOs or Data Transfer Objects. This is just a fancy way of saying, "We stuck all the data in some objects, now you deal with it." This is not really relevant to the discussion at hand, but it does show you what they are thinking about.

This topic is followed by a brief mention of REST. Now we see that the Entity Framework team have completely lost sight of what they are supposed to be building. Under "Goals" they say,

With the N-Tier improvements for Entity Framework, we want to address some of the same problem space as DataSet, but we want to avoid the primary issues with it.

Ideally, we would like to provide building blocks that are appealing for developers building solutions on a wide range of architectures. For instance, we would like to provide fine enough control for DTO proponents, but at the same time reduce the level of pain that those trying to address simpler scenarios experience today.

Now the problem is clearly shown; Entity Framework doesn't want to be just another ORM, it want to be everything to everyone. As we have seen time and time again, this approach usually makes no one happy. Consider this statement from the team,

Besides these two, there are a few more interesting generic representations for changes in a graph, but in general, they all suffer from the same disadvantage: providing a solution for them does not give the user the level of control that the most complicated scenarios and sophisticated patterns require.

This is followed with,

Entity Framework won’t define its own unique representation for the set of changes represented in an N-Tier application. Instead, it will provide basic building block APIs that will facilitate the use of a wide range of representations.

Since they cannot offer a 100% solution to the problem of manipulating change sets, they are not going to give developers anything. Developers have to build their own ORM on top of Entity Framework if they actually want to manipulate data outside a context.

The rest of the article is a rather lengthy example of how to perform even basic change tracking using their new API. This involves creating an interface such as IEntityWithChanges, mapping this using a hand-written method like GetEntityState, and using both in a method that takes an context object, entity state name, entity graph, and an entity state map. Keep in mind this is just for saving changes, you still have to somehow track the changes in the first place.

Ayende Rahien explains how it should be done:

Here is how you do this using NHibernate:

session.Merge( entityFromPresentationLayer );

Frans' LLBLGen support a very similar feature. In other words, it is the business of the data access framework to do this, none of the developer's business to do any such thing.

Speaking of Frans Bouma, here is his summary of the situation,

And how are all those dataset-using developers now going to be convinced the EF is the right way to go? When the DataSet has solved this problem since... oh well, the beginning? Not to mention as well as a lot of the competing O/R mapper frameworks out there? The core problem of all this is, I think, the mistake of designing the framework from the perspective of the framework developer: when you write a framework there are two kinds of 'correct': from the framework developer's point of view (POV) and from the framework user's POV. The core mistake is in the assumption that these two kinds of 'correct' are really the same, or worse: it's assumed that the framework developer's concept of what's 'correct' is actually what the framework user wants.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Always the same two concepts that Microsoft still not have admitted... by Frederic Monjo

IMHO, Microsoft culture suffers from two concepts they don't want to get out:
Now the problem is clearly shown; Entity Framework [...] want to be everything to everyone. As we have seen time and time again, this approach usually makes no one happy.

and
It's assumed that the framework developer's concept of what's 'correct' is actually what the framework user wants.


For the first one, Agile approaches says to be pragmatic: build something specific and iterate quickly to improve it with regard to the users' feedback.

For the second one, it's the good old "Developer thinks he knows what the user want"...

We know that it's a bad mindset from years ; what are they waiting for to change that ? They have the means, but they don't seem to use them correctly... Maybe it's one of the reasons of the increasing success of alternative products (Linux, Mac, Java, etc.) ?

Re: Always the same two concepts that Microsoft still not have admitted... by Dominique Ribaut

<blockquoteMaybe it's one of the reasons of the increasing success of alternative products (Linux, Mac, Java, etc.) ?>I can't see how Java is an alternative product in this context. Might it be the other way around?<//blockquote>

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss
BT