Skip Ribbon Commands
Skip to main content
Navigate Up
Sign In
Brian's Blog > Posts > Entity Framework: Vote of No Confidence
June 23
Entity Framework: Vote of No Confidence
by  Brian EllisNo presence information  on 6/23/2008 11:05 AM
Category: Work

I thought I'd post this summary that I sent out to our internal developer list earlier today. 

UPDATE: Tim posted his views on the EF and the open letter here.

--------

There have been a lot of complaints about the current implementation of the Entity Framework in the community and a bunch of the more visible alt.net figures have put together an open letter detailing what they see as its faults. 

http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

The purpose of this open letter is supposedly not to torpedo it, but to make Microsoft address these issues in the future.  I’m far from an expert in this but on a quick read-through, their complaints seem to be:

  • The design of the framework entities is that they are data only, causing issues in maintainability and making it difficult or impossible to implement business objects or more “real-world” objects. 
  • The design of the framework entities is that they cannot be persistence ignorant, so things like unit testing become next to impossible because you cannot test the model without the database (for instance).
  • Lazy loading is not supported at all and requires a lot of extra code to make work.  This confuses me.  I thought I saw "lazy-loading" demoed internally but I might be mistaken.
  • Shared, canonical models contradict software best practices.  This appears to be related to using a single shared model for multiple contexts in the EF, rather than multiple models, one for each individual context.  I’ll be honest, I don’t much about this other than what I read in the explanation.
  • Excessive merge conflicts with source control.  Apparently, since the diagram contains the model and the visualization, it causes tons of merge conflicts when a team is using it.

Just thought I’d pass this on.  It’s interesting from at least a best practices point of view.

Permanent Link to Post | Email Post Link | Number of Comments 6 Comment(s)

Comments

In defence of entity framework

The design of the framework entities is that they are data only, causing issues in maintainability and making it difficult or impossible to implement business objects or more “real-world” objects. 
Keith > Wrong, you use partial classes to extend the generated aspects of the entities. This is explicitly encouraged and we use it a lot for core business rules and validation

The design of the framework entities is that they cannot be persistence ignorant, so things like unit testing become next to impossible because you cannot test the model without the database (for instance).

KP > You can use the repository pattern around the EF and avoid using the object context directly. You are then only dependent on EntityObject, EntityReference and EntityCollection. i fyou are sensible about it and don't work on object context, your refactoring when vnext comes along will be significantly reduced.

Lazy loading is not supported at all and requires a lot of extra code to make work.  This confuses me.  I thought I saw "lazy-loading" demoed internally but I might be mistaken.
KP > By design, but pretty easy to wire it up, not really a "lot of extra code". I worked with NH too, and the time saved using the designer with EF more than makes up for it:)

Shared, canonical models contradict software best practices.  This appears to be related to using a single shared model for multiple contexts in the EF, rather than multiple models, one for each individual context. 
KP > Well, it may be a criticism of the vision of EF, but not of its core ORM functionality. Our clients are interested in the reporting aspects on their domains without excessive code.

Excessive merge conflicts with source control.  Apparently, since the diagram contains the model and the visualization, it causes tons of merge conflicts when a team is using it.
KP > A fair point, but we've settled on having a 'domain master', not a biggy for a smallish team, but perhaps larger would have problems..
Keith Patton at 6/23/2008 10:13 PM

In defence of entity framework

I've posted to my blog in defence of the EF, as someone who is actually using it, intead of criticising from an ivory tower!!

http://blog.keithpatton.com/2008/06/24/A+Vote+Of+Confidence+For+The+Entity+Framework.aspx
Keith Patton at 6/23/2008 10:24 PM

Re: Entity Framework: Vote of No Confidence

The Entity Framework Team has started work on Version 2 and invites people to take part in the design process/give feedback

http://blogs.msdn.com/efdesign/archive/2008/06/23/transparency-in-the-design-process.aspx#comments
Tom Pester at 6/24/2008 1:00 AM

EF

Keith: I think my co-worker Tim (linked above) agreed with you about partial classes.  I'm not sure what the alt.net guys are talking about.  The rest of the items seem to be best practice issues that can be worked around.  I think the alt.net guys goal is to for them to be best practice out-of-box next time around and not have to work around them.

Tom: Thanks for the feedback and link about the new version.
Brian Ellis at 6/24/2008 9:06 AM

alt.net objectives

Hi,
The alt.net crew should really have known and heard the v2 commitments around process and deliverables (POCO a la NH) and so i can see little for them to gain by the letter except notoriety. I think the best thing they can so is rally around Ayende in beefing up NH support for linq and maybe writing a decent designer tool for NH!
keith patton at 7/1/2008 4:52 AM

Validation

Actually built a validation framework that, except for changed property, fully works from the object context rather than the entities, so the entities do not have to be aware of validation rules (PropertyChanged seems to be a funny exception, but from a performance standpoint you already need to be careful what you validate on PropertyChanged). So you can enforce rules without using partial classes.
MR at 7/1/2008 12:59 PM