Stealing from your client
I had a (great) talk yesterday, introducing Active Record. During this talk, I reused Jeremy's statements about data access. If you write data access code, you are stealing from your client.
Frans Bouma puts it beautifully:
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?
The context for Frans' post was a design decision from the Entity Framework team. I read Frans' post first, and I didn't quite know how to react to it, until I saw what the proposed design is. You can read the entire EF post here, but I'll try to summarize it so you can actually understand the point without going and reading the whole thing.
The problem is supporting change tracking in disconnected scenarios. In particular, you take an object from the database and send it to the presentation layer, some time later, you get the object from the presentation layer and persist it to the database again. There is a whole host of bad practices and really bad design decisions that are implicit in the problem statement, but we will leave that alone for now.
This is still a pretty common scenario, and it is more than reasonable that you would want your data access approach to support this.
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.
The current proposed EF design problem can be summarized in a single line.
This is code that you as the user of EF, is supposed to write.
If you write this type of code, you are stealing from your client.
This design violates the Infrastructure Responsibility Principle: Developers doesn't write infrastructure code for supported scenarios.
In other words, it is okay not to support a feature, but it is not okay to say that this is how you are supporting a feature.
This Is Broken, By Design