Baby-sitter Framework 2.0: Change tracking in the EF v2, it's still your problem
More than 1.5 year ago (!) I wrote an article about why change tracking of changes of an entity should really be inside an entity object. Change tracking is the concern of the O/R mapper and the entity object, not the developer using the entity object and the O/R mapper. Imagine using an entity object a .NET application and you are in charge of taking care of what changes happened inside the entity object when it was used by some routine so you can decide which routine to call: the InsertNewEntity() routine or the UpdateExistingEntity() routine. Isn't that the concern of the framework you're using? I.o.w.: why do you need to baby-sit the changes of an entity and make sure these changes are propagated along the same path over which the entity travels?
The Entity Framework (EF) v1.0 has a non-existing answer to the 'n-tier problem' or better: how to deal with changes on an entity that's not directly connected to a live context. This obviously lead to a lot of negative feedback on the EF, and Microsoft replied as much as that they would seriously look into this problem for v2.0 of the EF and would try to solve it properly. Well, yesterday, the EF team posted a proposal of the v2.0 'solution' to this problem: you solve it. They give you the API, and you, the framework user, the person who is paid to write code on top of the used frameworks, not for the used frameworks, will write code to solve the change tracking problem.
Honestly, with their council of wise men in charge of telling them what to do, who came up with this 'solution' ? With a few exceptions, in general developers aren't paid to write frameworks, they're paid to write applications for the customer: the sooner they're done, the more they can build on top of proven technology which is used by many people, the less bugs they'll create and the less problems the customer will have. If the developer is forced to invent a change tracking strategy, thus spend time on how to solve a framework-related problem, the developer will spend time on plumbing code, which will have to be designed, debugged and tested.
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.
That's not the case. A framework user doesn't give a **** about how many different patterns the framework is using and how great and awesome it's internally and how it will ultimately evolve in the bringer of world peace. A framework user is interested in whether the framework takes care of things the framework user can't afford to spend time on. After all, the framework user can't afford to spend time paid by the customer on plumbing, on writing infrastructure code. The framework user is paid to write code directly related to the problem at hand: the application for the customer. No customer should accept that the team hired for writing the line-of-business application has spend time on writing a report-control or for example a grid control. So why should a customer accept to pay for time spend on other plumbing code? Just because the customer doesn't know any better? If so, isn't that erm... taking advantage of the inability of the customer to judge what the 'software guys' did was correct?
Yes, it's that extreme. The software industry should grow up and realize that it shouldn't be acceptable anymore to write frameworks and framework code, plumbing code etc. paid by the customer, just because the customer doesn't know any better. And we, the software developers, should grow up and accept that the job many of us have isn't to write plumbing code and infrastructure code, but to write code using the plumbing available. If the plumbing at the place where you work is broken, it's very likely that someone will call a plumber to fix it. So why accept that if the plumbing used for a project is broken, one has to fix it themselves? With all the bugs, loss of time, focus and ultimately: money, as a result?