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.