Why use the Entity Framework?

There are a number of places where you can read an introduction to the Entity Framework, listen to a podcast about it, or watch a screen cast or video of an interview.  Even with these various resources, though, there are so many different data access technologies out there that it’s not uncommon for me to get the question: Why should I use the Entity Framework?  Or what differentiates it from other options like just using ADO.Net SqlClient and friends, LINQ to SQL or something like nHibernate?  I like the second question better, because the truth is that different problems merit different solutions.  So here’s just a quick take on my perspective about these:

Entity Framework vs. traditional ADO.Net
All of the standard ORM arguments apply here.  The highlights are that you can write code against the Entity Framework and the system will automatically produce objects for you as well as track changes on those objects and simplify the process of updating the database.  The EF can therefore replace a large chunk of code you would otherwise have to write and maintain yourself.  Further, because the mapping between your objects and your database is specified declaratively instead of in code, if you need to change your database schema, you can minimize the impact on the code you have to modify in your applications–so the system provides a level of abstraction which helps isolate the app from the database.  Finally, the queries and other operations you write into your code are specified in a syntax that is not specific to any particular database vendor–in ado.net prior to the EF, ado.net provided a common syntax for creating connections, executing queries and processing results, but there was no common language for the queries themselves; ado.net just passed a string from your program down to the provider without manipulating that string at all, and if you wanted to move an app from Oracle to SQL Server, you would have to change a number of the queries.  With the EF, the queries are written in LINQ or Entity SQL and then translated at runtime by the providers to the particular back-end query syntax for that database.

Entity Framework vs. LINQ to SQL
The first big difference between the Entity Framework and LINQ to SQL is that the EF has a full provider model which means that as providers come online (and there are several in beta now and many which have committed to release within 3 months of the EF RTM), you will be able to use the EF against not only SQL Server and SQL CE but also Oracle, DB2, Informix, MySQL, Postgres, etc.

Next there is the fact that LINQ to SQL provides very limited mapping capabilities.  For the most part L2S classes must be one-to-one with the database (with the exception of one form of inheritance where there is a single table for all of the entity types in a hierarchy and a discriminator column which indicates which type a particular row represents).  In the case of the EF, there is a client-side view engine which can transform queries and updates made to the conceptual model into equivalent operations against the database.  The mapping system will produce those views for a variety of transformations.

You can apply a variety of inheritance strategies: Assume you have an inheritance model with animal, dog:animal & cat:animal.  You can not only do what L2S does and create a single table with all the properties from animal, dog & cat plus a column that indicates if a particular row is just a generic animal or a dog or a cat, but you can also have 3 tables where each table has all of the properties of that particular type (the dog table has not only dog-specific columns but also all the same columns as animal), or 3 tables such that the dog and cat tables have only the key plus those properties specific to their type of animal and retrieving a dog object would involve a join between the animal table and the dog table.  And you can further combine these strategies so some parts of a hierarchy might live in one table and some parts in separate tables.

In addition you can do what we call “entity splitting” where a single type has properties which are drawn from two separate tables, and you can model complex types where there is a type which is nested within a larger entity and which doesn’t have its own separate identity–it just groups some properties together.  The best example of this is something like address where the street, city, state and zip properties go together logically, but they don’t have independent identity.  The address is only interesting as a set of properties that are part of a customer or whatever.  As you have noticed, for v1 you can’t create complex types with the designer in the EF–you have to code them by hand in the XML files.

Entity Framework vs. nHibernate
Because nHibernate is a rather full-featured ORM, the distinguishing features between the EF and it are not as large.  In fact, it is certainly true that nHibernate is a more mature product and in many ways has more ORM features than the EF.  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 EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes.  This makes it easier to create a conceptual model which is how you want to think about your data and then reuse that conceptual model for a number of other services besides just building objects.  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.  Not only does this increase the value of the data model by allowing it to be reused for many parts of your overall solution, but it also allows us to invest more heavily in common tools which will streamline the development process, make developer learning apply to more scenarios, etc.  So the differentiator is not that the EF supports more flexible mapping than nHibernate or something like that, it’s that the EF is not just an ORM–it’s the first step in a much larger vision of an entity-aware data platform.

Comments (45)

  1. JohnPapa.net says:

    I’ve prepared dozens of articles and presentations on the Entity Framework over the past year and a half and the questions always start with "Why would I want to use this instead of XYZ?" LINQ to SQL, a variety of ORM tools, straight up ADO.NET, custom

  2. I've prepared dozens of articles and presentations on the Entity Framework over the past year and

  3. I've prepared dozens of articles and presentations on the Entity Framework over the past year and

  4. Daniel Simmons vient de publier un post sur lequel il explique pourquoi EF c’est bien en le comparant

  5. Danny Simmons has a post on why to use Entity Framework .  Here's my main gripe with Danny's

  6. chadmyers says:

    But I don’t want EDM. I don’t want to model my RELATIONAL MODEL database in my OBJECT ORIENTED .NET system.

    I want to MAP from one incompatible model to another, which is why I use an OBJECT/RELATIONAL Mapper.

    From what you’re describing, EF is not an O/RM at all, it’s a data model mapper to allow you to bring all your relational data modeling problems into your object-oriented world, making the relational problems even more complicated than they were before.

    It turns out databases are pretty good at dealing with relational models and .NET is good at dealing with object models and the two are quite different. Wouldn’t it be easier to take advantage of the strengths of both systems and push the ugliness of mapping from one system to another into a framework like NHibernate?

    From what I’ve seen, and from what you’re saying w/r/t to EDM, EF is all about the classic data access approach of materializing my relational model as objects.

    It seems we’ve been trying this for many years in various incarnations and it’s never been successful and I doubt this one will work well because the fundamental problem is: You can’t work effectively with relational models in an object-oriented world (or vice versa).

  7. simmdan says:

    Have you looked carefully at the mapping capabilities of the EF?  EDM is not a relational model.  It is a conceptual model which is much like the object-oriented system you get in .net, and as such it can do (and eventually will do) all that an ORM can. The limitation of an ORM, though, is that you can’t easily reuse the mapping exercise you have done and the mental model you have created with your object model in other contexts.

    That said, I’m not trying to convince everyone to drop nHibernate, that the EF is better than nHibernate or any such thing.  I’m trying to help clarify what makes them different so that you can make your own decision about the best tool for your situation.

  8. You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

  9. Danny Simmons wrote a marketing piece about the project he's been working on for so long: "

  10. chadmyers says:


    I actually don’t care that much about NHibernate. I care about layered architecture, separation of concerns and, specifically, persistence ignorance.

    All hats off to the NHibernate folks, but to be honest, NHibernate has a lot of warts and isn’t the perfect O/RM, but it’s the best we’ve got so far (from my experience).

    So if EF does a better job at SoC and PI, then I’m all for it. But (again, admittedly only from what I’ve HEARD/READ), it sounds like EF requires me to litter my domain model with all sorts of persistence concerns and necessarily forces me to think about persistence when working with the domain model and business logic. This is not good and is a step in the wrong direction and is only marginally better than SQL statements directly in the middle of my business logic (both involve persistence concerns where they shouldn’t be).

    To be fair, I’m not JUST picking on EF here, because other so-called ‘ORM’s make this mistake also.

  11. simmdan says:


    Your concerns about persistence ignorance are understood.  Sadly with all of the other things going on in the first release we were unable to get all the way there.  There are things you can do to mitigate these concerns somewhat in v1, but I think you’ll see a better picture in v2.

  12. JimmyBogard says:

    I think it’s a mistake to share a data model with anyone outside your bounded context (see Evans, Domain-Driven Design).  It’s also a mistake to share a conceptual model or a EDM or whatever we’re calling this.

    I never want domain objects exposed directly via services.  That’s violating the encapsulation I’m trying to create.

    If someone wants SSRS, then I give them a separate reporting database, tailored to reporting needs.  I don’t want reporting concerns bleeding into my transactional concerns.  A mapping layer will not solve this problem, products like SSIS can.  You want reporting? Here’s your read-only view, updated every hour, five minutes, daily, whatever.

    Sharing a connection string is sharing a connection string, no matter how much lipstick you put on that pig.

  13. Dan Simmons from the Entity Framework team at Microsoft made a nice post comparing the Entity Framework

  14. Dan Simmons from the Entity Framework team at Microsoft made a nice post comparing the Entity Framework

  15. LA.NET [EN] says:

    Well, I'm still skeptic about it…and it seems like Frans Bouma decided to comment Danny Simmons

  16. ASPInsiders says:

    Well, I'm still skeptic about it…and it seems like Frans Bouma decided to comment Danny Simmons

  17. gOODiDEA says:


  18. gOODiDEA.NET says:

    Debug ASP.NET Tips: What to gather to troubleshoot – part 5 – OutOfMemoryException .NET Why use the Entity

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

  20. I have to agree with what Chad Myers and Jimmy Bogard are saying. It worries me that yet again, Microsoft seem to be favoring RAD over best-practice.

  21. Ross Hawkins says:

    Some light reading on the Entity Framework

  22. Hot Topics says:

    Danny Simmons discusses the benefits of Entity Framework . Comments and analysis by In favor: Roger Jennings

  23. BenScheirman says:

    +1 To Jimmy Bogard’s comments.  Reusing your EDM or conceptual model outside your immediate control will couple your application and all of it’s related consumers with your schema (be it relational or whatever).

    This will prohibit change rather than enable it.

  24. Peter Ritchie says:

    From Fran’s blog;

    Danny, if I’m a traditional TDD methodologist (for lack of a better term) and I’m building up my code base with test-first mentality then it’s all about the code.  The automated tests are used for documentation of things like requirements, user stories, etc.  Agile folk try to avoid documents like conceptual models, our conceptional model is the code, it’s our classes.  I don’t need another conceptual modeler and I don’t need to have a modeler create new classes for me, I don’t need it to modify my classes, the classes I’ve defined for my application do exactly what they need to do.

    As we build up our classes to reflect what the domain is, as we know it now, we eventually want to add the ability to persist those objects to a store of some sort.  It’s at that point we being to think of OR/M.  But we want to keep that persistence separate from our abstractions, keeping true to the single responsibility principle and separation of concerns.  All the trappings of persistence are abstracted somewhere else.

    Reporting will never map to the behavioural model that we’ve declared in our object hierarchy, it’s about the abstract concepts for that application, not reporting.  The needs and requirements of reports may be entirely orthogonal to what we need in our application-centric abstractions.   An application may or may not do reporting, but this "EDM", I gather, is about pushing that conceptional model into other tools like BI tools, etc. that are completely separate from the application.  I’m not going to, and never will, design a class hierarchy whose conceptional model will be used in another tool

    If I’ve built up my entity hierarchy with a TDD mentality, how can I push that hierarchy into EF and keep it up to date as my entity hierarchy evolves with refactorings, etc?

  25. simmdan says:


    Well, it certainly depends on the nature of your situation and the application you are building.  Certainly I might build a domain model which is a different shape than the model I want to report on.  That might even be true in many cases, but in those cases there’s a pretty chance I might want to take my domain model and use it as the basis for synchronization to take entities as a whole between my mid-tier and a client for offline use, or I might want to build a workflow on top of those entities using some workflow activities that are already aware of and can leverage the metadata around my model.  Even for the case of reporting where I end up building two different models–one that’s conducive to my business logic and another which is the way I want to think about my reports, one of the first things I do when I start to build reports (especially customer self-service ad hoc reports which are part of many systems) is that I create a conceptual model.  If I’m going to create such a model, wouldn’t it be nice if I could use some of the same modelling language (textual representation, tools, etc.) to do it?

    – Danny

  26. simmdan says:


    In a number of situations, this is the reality that we live in whether we like it or not: There are several components to my overall solution each of which needs a conceptual model.  In that kind of situation, sometimes the same conceptual model makes perfect sense, and why should I have to create two copies of effectively the same model just because different tools have different ways of specifying it?  At other times, I may decide to use two different models over the same data in order to create models which are more appropriate for their use or to isolate one from changes in the other, but even then there’s value in using a common language and set of tools to create the models.

    The EDM is all about creating some common mechanisms describing and reasoning about models.  The Entity Framework is one tool that can use the EDM.  We’re working to create additional tools or modify existing tools to leverage this same understanding.

    – Danny

  27. BenH says:

    Great post!  I created a post that builds on this info to give some guidelines on when to use what technogies.  Check it out here:


    I’d love to get your feedback on my opinions.

  28. simmdan says:


    Sure, your guidelines are reasonable for a first cut.  The only other things I would say are:

    a) While 1-1 mapping is sufficient for some simple applications, it will often come to haunt you sooner than you think.

    b) There are more ORM solutions out there than EF and nHibernate.  It’s worth taking a look around to see what really fits your needs.  Naturally I think the EF is good in a lot of scenarios, and in the next few releases I think it will get a lot better, but that doesn’t mean that it’s the perfect solution for every problem now or even if you posit some future where all my crafty plans for making the EF better come to fruition.  🙂

    – Danny

  29. It seems that everyone else is chiming in on Danny Simmons’ recent comparisons of the Entity Framework

  30. Links of the Week #39 (week 22/2008)

  31. Zunanji viri says:

    Development Why use the Entity Framework? – Everybody wants to know… Microsoft Source Analysis for

  32. colinjack says:

    On EF vs LINQ to SQL I’m wondering why, instead of hammering LINQ to SQL you guys aren’t adding features to it. Essentially the issues you raise regarding LINQ to SQL relate to missing features but even without those features it does seem a lot more attractive than EF.

  33. jemiller says:

    Personally, I wish Microsoft could have come up with a single solution instead of having both LINQ to SQL and LINQ to Entities. Given the fact that LINQ to SQL doesn’t even have a many-to-many mapping, it’s pretty much a non-starter for me. This is a small thing, but, I wish they would drop the ADO naming. Fortunately, Microsoft is starting to do things right with .NET. Having a name with ActiveX in leaves a bad taste in my mouth.

  34. As I started to learn more about Entity Framework, i stumbled upon an interview with Quentin Clark who

  35. The Entity Framework team should talk to the MVC team

  36. #.think.in says:

    #.think.in infoDose #19 (23rd Feb – 27th Feb)

  37. nappisite says:

    This is the same argument I’ve been having with myself recently.  Trying to figure out, if I going to migrate code away from old style ADO.NET which O/RM-ish tool do I use if any.  I’ve seen a lot of bashing of EF, and in its simplest form its very similar to L2S.  Compared to NHibernate, if that’s what you’re already using, then there probably isn’t much of a debate. For those of us still using datasets to hydrate our objects, and stored procedures to persist them, I think EF and L2S both have some compelling advantage to eliminating a lot of boilerplate CRUD code.  At this point that’s all I’m looking for. But its very interesting to know that Microsoft sees a bigger role for EDM, and if we us EF for our data access now, we can grow with it as it grows.

  38. Matt says:

    So now that it's two years later and EF has changed considerably from it's pre-1.0 days, how does this comparison change, specifically the EF vs NH?

  39. simmdan says:


    Just my opinion, but most of the key points of the EF vs. NH comparison are still the same.  The EF is more mature than it was when I originally made this post which (among other things) means that it now has parity with regard to a number of additional ORM features that used to be differentiators for NH.  In addition some of the integration with other Microsoft products has come more slowly than I originally hoped, but there are a number of offerings now available in products like Ria Services, Data Services, Dynamic Data, LightSwitch etc. which demonstrate the core principle.  The EF is an ORM, but it's also a key part of a much larger story.

    – Danny

  40. NMittal says:

    Hi Danny,

    I totally agree with the Entity Framework vs Linq to SQL, but I am not able to understand: .Why Linq to SQL is not extended rather creating new Entity Framework



  41. Hi Daniel,

    How about the performance of EF? I'm aware about it.

    The EF is slower than ADO.NET; because ADO work directly with database.

    Do you think so?

  42. Jeffrey Roughgarden says:

    I'd be very interested in an updated version of this post. Do you have time?

  43. northland5 says:

    Concur with Jeffrey R. An update to this post would be good to read.

  44. hhhhh says:

    Jeffrey Roughgarden 4 Jun 2013 11:10 AM #

    I'd be very interested in an updated version of this post. Do you have time?

    John Tragis – FNSB1 9 Jan 2014 11:13 AM #

    Concur with Jeffrey R. An update to this post would be good to read.