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?

8 Comments

  • Well Frans, I understand your point but for the sake of fairness let me add two thoughts concerning this.

    1. As I understand the post the EF will leave the design decision to the user(developer) but will provide support paths for all kind of API usage e.g. EntityObjects or POCO entities.
    This means more work for them and more freedom to decide which route to go for the user.

    2. In a certain ways you are doing the same thing in LLBLGen as you provide a SelfService and a Adapter Paradigm and leave the user with the decision.. or I am misunderstanding you here?

    Adrian



  • Less is more!

    To the CoW Men, I say moo.

  • @Adrian:
    "This means more work for them and more freedom to decide which route to go for the user."
    The user has to develop something to make things work, which isn't the concern of the user, the user is _using_ the framework, and the framework should provide the services, not the user. Make no mistake: the user has to babysit the changes, has to write code to make everything work together and make sure this works in the cases the app is used in.

    "In a certain ways you are doing the same thing in LLBLGen as you provide a SelfService and a Adapter Paradigm and leave the user with the decision.. or I am misunderstanding you here?"
    That's a total different thing. Choosing between selfservicing and adapter is like choosing between winforms and WPF for your windows application: both get the job done and provide services to you which you would expect a framework to provide.

    The point of the article is that there's NOT a service provided, for a piece of functionality which is clearly the concern of the framework, so the user has to provide that functionality, test it, debug it, maintain it.

  • There are a number of ways to interpret the EFDesign blog article:

    1) The DP group are well aware of how flawed 'entity framework' is, but with the price tag attached to it they can't exactly go and tell the boss the truth. He will throw chairs and stuff. So instead they inject more design flaws into the core of it while working on something else, the _next_ data access framework.

    ...alternatively...

    2) The DP group really have no experience from business app development. Apart from the PMs, they're all fresh out of college, but with really good degrees.

    ...or...

    3) They really mean it. In that case, we all know what happens next.

    That aside, shouldn't someone take the "ado" name tag away from those people? At least ADO 2.x did properly handle change tracking across tiers in n-tier scenarios. The current stuff don't...

    Kris

  • While its nice to allow me to provide that service if I have some strange requirement, I shouldn't need to provide the service if I have a normal situation.

  • Microsoft is a platform company.

    They build technologies that partners can build stuff on top of.

    It's what they've always done.
    It's what they're continuing to do.

    Unfortunately, many developers in the Microsoft community don't know/understand this, thinking that these technologies are supposed to be used to build applications directly. This often causes overly complex codebases.

    The EF's team's decision is consistent with providing a platform for partners to build their own ORMs on.

    That being said, I don't care very much for a platform - just as I wouldn't drive the chassis of a car.

  • This is just amazing, I cannot believe that they have gone down this route. They really did not hit the ball with Linq to SQL either and they canned that.

    IMO I think they should have invested the effort in making LINQ to SQL better and added better disconnected support and they would have been on a winner.

    But yet again with the EF we get something that does not quite meet our needs/expectations of things we have gotten used to LLBL and NHibernate that just 'work' with minimal friction.

    One day one day the mothership will deliver :)...

  • It seems like a strange decision to me, unless @Udi is correct on Microsoft's focus. To me it reminds me of the shift from C++ to C#. In C++, the user of a framework (particularly the XML frameworks IIRC) was responsible for the memory management of objects in the framework, whereas C# handled all that, and let you concentrate on the job in hand. Pushing db change management onto the user sounds like the same problem, and is liable to suffer from some of the security and performance issues that were caused by programmers forced to roll their own C++ memory management.

Comments have been disabled for this content.