On Comparing Current Tools to Futureware

I’m going to take a quote from Daniel Simmons on why we should use the Entity Framework.

I’m not specifically interested in his comparison with NHibernate because I think the following is true of many current O/RMs (whatever your personal flavor happens to be).  I am, however, going to quote it because it caught my attention.

The big difference between the EF and nHibernate is around the Entity Data Model (EDM) and the long-term vision for the data platform we are building around it.

The biggest problem with comparisons like this is that you can’t compare unwritten software with something that’s already in production today.  The false assumption underlying this is that the current breed of O/RMs will stand still while Microsoft magically comes from behind to deliver an innovative platform.  It just doesn’t happen like that.

So how does the EF differentiate from the current breed of O/RMs?  Apparently, it doesn’t.  That’s slated for the next version.

Here are a few other reactions that I agree with, that hit my RSS reader today:

• Why use the Entity Framework? Yeah, why exactly?
  • Reaction from Jeremy Miller
    • Why EF?
      • More Entity Framework Thoughts
        • EF Long Term Plans
          • Entity Framework: Our Albatross
            • Rewriting the Entity Framework Source Control Support </ul> In short, the Entity Framework is a 1.0 release.  Expect from that what you will.

            Let’s just hope that the next version (or two) will hit somewhere near the mark–although I do have really big concerns about some of the design decisions they are pushing (such as reusing the models all over the place).  It sounds like an expensive and delicate design to maintain.  Smearing any kind of structure or model (data, object, or conceptual) makes change to that model quite a bit more expensive.

            That is, in fact, software design 101.  David Parnas was writing about it all the way back in 1972.

            Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc

            While it often seems like a good idea to expose things like entities to the outside world (it’s reuse, right?).  The illusion quickly gets shattered when you start looking at how things will change in the future.  Sharing data models usually means spreading the associated logic around.  Spreading logic around means duplication.  Duplication is costly to maintain.  It also has very real coupling issues. 

            Also, if adding a new field to the Customer entity requires many changes (both in your app and in your consumer’s apps), you’ve done a piss poor job of design (think: sharing internal models across service boundaries).

            But not only that, but I find that this type of thinking leads straight into CRUD.

            I’m going to stop here because I’m quickly winding my way into a design death spiral.  And I think you get my point.