What Dan Simmons forgot to tell you about the Entity Framework

Posted by Jeremy Miller on May 19, 2008

Dan Simmons from the Entity Framework team at Microsoft made a nice post comparing the Entity Framework to other existing tools.  I wanted to pick a little bone with his comparison to NHibernate.  I don’t think he said anything inaccurate, and he was very fair minded, but he left out the crucial fact in any consideration of using NHibernate versus the Entity Framework.  The Entity Framework is very intrusive into your application, but NHibernate is not.  NHibernate lets me use POCO’s to model the business process in a database agnostic way.  The Entity Framework wants me to bake EF infrastructure directly into my business objects.

The major problem I have with the Entity Framework is very apparent in Dan Simmon’s post.  The EF team, and its advocates in the blogosphere, are strictly focused on data.  The last I checked, an application, system, or service usually consists of more than just getting data in and out of a database.  Some of that other stuff is quite challenging as well.  I’d prefer to be able to make that other stuff work in peace without data access infrastructure concerns bleeding into my business classes. 

I would really like to challenge the EF team and the EF cheerleaders to be more cognizant of the entire application architecture instead of focusing strictly on the grubby details of data access. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://my-tech-talk.blogspot.com/ Tobias Manthey

    If you ask yourself how to get the data into *your* business (POCO) object, EF4 still gives you absolutey no answer. But much worse is the fact, that you can’t even get the ORM objects in your structure. Look at what EF4 calls a “ComplexType” and find out that it is a pure scalar type.
    All EF4 basically does is to give you an object representation of database tables with LINQ und changetracking support. End of story.
    I cant see any OR*Mapping* in EF4.

    See: http://social.msdn.microsoft.com/Forums/en-US/adonetefx/thread/e0092fa1-46d5-4727-ab8c-faa61cac091e

  • Sean

    I have been toying around with EF and EM now for a couple of weeks, and found if you design your system you don’t need to connect EF into your business layer.

    Simple mapping from entity to DTO and most things seem to work fine. I think the improvements in VS 2010 ( mainly in the designer ) really enhance certain aspects for the creation.

    Had previous bad experience with NH, maybe the initial project wasn’t set up correctly or the database but the fact it seemed to be disappearing into a black hole for the connection bothered me.

  • anon

    as someone who used to work on the .net team (and still remains friends) with many early .net team members, i think that the microsoft .net team has completely lost it’s way.

    damn near everything post 2.0 is a mess.

    compare WPF to Adobe Flex/Air. WPF is a nightmare compared to the simple and easy to use Flex.

    WCF is a configuration nightmare (which only eludes to the underlying overly-engineered, overly-complicated, ugly, architecture underneath). compare WCF to earlier incarnations.

    WF is also a nightmare. look at the model for creating tracking services. it was literally designed backwards.

    generics are awesome until you really get into the meat grinder with them and realize that the underlying subtleties weren’t thought through at all.

    the EF team is a joke. this reminds me a lot of the Patterns and Practices group, where they literally made up a bunch of patterns, told people that “everyone in the enterprise space is using them” and sold people into using them. subsequently, the team was gutted, and they’re still trying to fix their reputation from it.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @EricTN,

    Man, I hate to be pessimistic, but the EF team has been getting this feedback for over a year with no announced plans to fix the problems.

  • EricTN

    You make a great point about there being only a database centric focus. On the other hand, this is a 1.0 release. Great feedback and commentary from people like you may have Microsoft broadening the focus and making things more elegant in future releases. 1.0 is 1.0.

  • 5x1llz

    cosign the need for awareness of different ways to drive out your architecture….

    I personally want to use POCO’s and keep them free ( by any means necessary ) of any attributes, properties e.t.c. that are solely related to data persitance. This might work if there was a seperate suite of classes altogether just designated as DTO’s.

    I thought the whole idea of ORM was to simplify and support OOP principles instead of sending us forwards into the past.

    Patrik, thanks for that succint distinction between EDM and EF. It seems EDM will be more useful than EF especially if it allows you to (easily) map to other non-EF ORM providers.

  • http://www.lowendahl.net Patrik Löwendahl

    The question is this, does everybody understand the full strategy behind EDM? And would you rather have Typed DataSets as the Microsoft preferred application model of data?

    The EDM and EF are separate things, the EDM is for creating models and the EF is the ORM. The architecture of EDM / EF is layered and separated in such a way that it is possible to build your own ORM above the EDM (or maybe create a NH dialect / provider).

    I don’t suggest that that’s the first thing you should runaway and do, but this clearly shows that the intentions of the EDM is far broader then that of the EF.

    A sum-up: http://www.lowendahl.net/showShout.aspx?id=207

  • Eric

    I like NHibernate but it is somewhat intrusive with respect to the need to make public props/methods virtual in order to do proxys for lazy load. Certainly, not as severe as DAL inheritence but still annoying.

  • http://www.opgenorth.net Tom Opgenorth

    I don’t think the EF team and EF cheerleaders are the only ones guilty of this narrow focus on data access.

    It seems that a lot places these days view the application as merely a portal through which to view the application. Many of the contracts I work on have a mentality of “one screen – one stored proc” and treat the application as just a way to get the stuff from the database to browser (or WinForm app).

  • http://scottic.us Scott Bellware

    Why are we surprised that a team with a data focus has neglected to consider what the term “Entity” means in the business layer, or that the bounded contexts of data and business logic might have necessarily and advantageous differences in the definitions of terms in their dictionaries of terms?

    The Entity Framework is more specifically the Data Entity Framework. It’s this distinction that shows clearly and directly that the EF team is out of its element in producing a framework for object oriented application development that makes use of a business data store.

    “Entity” means something specific in a database, and is treated a specific way in that context.

    “Entity” means something specific in an object-oriented program environment, and is treated a specific way in that context.

    An EF “Entity” is an architectural travesty for not recognizing the difference in the contexts and the great advantages to building software with an awareness of the differences.

    The EF team’s persistence in refusing and recognize these basic application architectural issues raises questions of ethics for me.

    In the end, the EF team operates under a safe harbor by shipping a framework that the EF hounds persist in calling an ORM, while simultaneously telling community leaders that the EF is not really an ORM in off-the-record conversations.

    The EF team would be able to put themselves right back into the center line of ethics and responsibility to Microsoft customers and customer potential by stating clearly and for the record that the EF isn’t really an ORM as they have said in private to insiders.

    When we simply get back to seeing the EF as a pretty good query engine, we’ll be able to use the tool to achieve the success that it’s intended for rather than drag it into architecturally-irresponsible scenarios so as to justify the continued budgeting of the project by trumped up adoption predicated on misrepresentation.

  • http://neilmosafi.blogspot.com Neil Mosafi

    Oh really? That sucks hard! I was under the impression that you could use any object for your entities if you want and the mapping layer would be separate (just like NHibernate or Linq2Sql). I guess I was mistaken.

    It also leaves a sour taste in my mouth to read that lots of new frameworks are going to be built which automatically take advantage of EF (such as Astoria)… why can’t those frameworks just use POCOs and leave it up to the developer to plug in persistence providers of their choosing? Strange decisions