The application I am currently building has been using Stored procedures and hand-crafted class models to represent database objects. Some people have suggested using Entity Framework and I am considering switching to that since I am not that far into the project. My problem is, I feel the people arguing for EF are only telling me the good side of things, not the bad side :)

My main concerns are:

  • We want Client-Side validation using DataAnnotations, and it sounds like I have to create the client-side models anyways so I am not sure that EF would save that much coding time
  • We would like to keep the classes as small as possible when going over the network, and I have read that using EF often includes extra data that is not needed
  • We have a complex database layer which crosses multiple databases, and I am not sure EF can handle this. We have one Common database with things like Users, StatusCodes, Types, etc and multiple instances of our main databases for different instances of the application. SELECT queries can and will query across all instances of the databases, however users can only modify objects that are in the database they are currently working on. They can switch databases without reloading the application.
  • Object modes are very complex and there are often quite a few joins involved

Arguments for EF are:

  • Concurrency. I wouldn't have to code in checks to see if the record was updated before each save
  • Code Generation. EF can generate partial class models and POCOs for me, however I am not positive this would really save me that much time since I think we would still need to create the client-side models for validation and some custom parsing methods.
  • Speed of development since we wouldn't need to create the CRUD stored procedures for every database object

Our current architecture consists of a WPF Service which handles database calls via parameterized Stored Procedures, POCO objects that go to/from the WCF service and the WPF client, and the WPF desktop client itself which transforms POCOs into class Models for the purpose of Validation and DataBinding.

So my question is, is EF right for this? Are there any pitfalls about EF that I am unaware of?

  • Check out this too .. a comparison of performance and LINQ support: ormeter.net
    – M.Sameer
    Mar 16, 2011 at 23:38

6 Answers 6


I was recently evaluating Entity Framework and the best place I found for issues and missing features was: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

The items with most votes:

  1. Support for enums. This one is pretty big, but there are currently some workarounds
  2. Improved SQL generation. Speed is really important especially for enterprise level applications, but it seems like with EF4 it has improved a lot
  3. Support for multiple database. Requirement for any large application.

There are many more issues in the User Voice list.

On a side note, I am pretty excited about upcoming release of EF 4.1 that will include Code-First approach... Link

This may actually push me to try EF in a production application.

  • Argument against: 1st & 2nd & 3rd: It's SLOW !!! There's a learning curve (need to know how to do a left join - takes 3 hours to find out a way how to do it so another person will know what is being done...), paging in LINQ instead of SQL (e.g. feches 10 milion rows, then takes 20 of them from an arbitrary offset, and then you wonder why it is that slow)... The Repo is Non-Tread safe, you have to init it on a per query basis, and repo initialization is VERY SLOW (like 5 seconds) if you have a larger database (that means 100-200 tables, not REALLY REALLY large).
    – Quandary
    May 9, 2014 at 7:19
  • 2
    @Quandary Seems like you're executing IQueryables (i.e. calling .ToList() or .ToArray) before your LINQ expressions are fully defined. That's why it pulls all records and make it slow.
    – orad
    Jul 27, 2016 at 12:33

Doing branch-per-bug/feature with EF can be remarkably painful at merge time. Imagine that two branches A and B make changes to the database (which will probably happen a lot during the early stages of a new project).

You merge all the "normal" files - cs files, etc. And then it's time to merge Model.edmx. And suddenly you're not just merging the logical mappings between your object model and database, but also the positions of tables in the entity diagram.

Merging Model.edmx is so painful that we adopted a fairly nasty Way That Works:

  • During the merge, just select all the merges from one parent. Which doesn't matter; you'll toast the file soon anyway:
  • Revert Model.edmx to either parent.
  • Migrate your database to the new merged state.
  • Open the Model.edmx, and "Update Model from Database".
  • Rename all the navigation properties toasted during the merge.
  • 1
    This criticism is not valid for EF Code First but does apply to Model First and Database First. Oct 11, 2013 at 23:36
  • I create all the mappings myself using Fluent and take full control of the mapping. These are placed inside a separate .cs file. Feb 5, 2015 at 9:33

There's a couple other benefits to EF you are missing:

  • You can have an Entity span tables
  • You can split a table into many types of Entities
  • You can generate the Entities from the database (i.e. database as master approach)
  • You can generate the database from Entities (i.e. code as master approach)
  • LINQ queries are translated to SQL queries, improving their performance.

The downsides (particularly if you are using validation):

  • You have to create a [MetadataClass] attribute that points to another class that has the properties you want to validate with the appropriate validation attributes. All the properties are object types, so it's just there to read the metadata. Still a lot of extra inactive code.
  • Using EntityFramework is a different concept than the way something like NHibernate (and the parent Java version as well) is designed to work. EntityFramework does best in an attached mode where the objects are using a live connection at all times. NHibernate and similar ORM tools work best in detached mode where the connection is only used when loading/saving data.

Those are the two biggest complaints I have. There's a number of benefits, but you very well might be able to get those same benefits from NHibernate. If EntityFramework is on the table, have the team also check out NHibernate and do a quick shoot out for the pros/cons for your project.

The metadata class problem is a headache, but thankfully I only have so many entities that need validation tags.

Lack of a true detached mode for your objects limits what you can do in a web environment. Attached mode is better for desktop applications, which is where a number of Microsoft innovations have originated. Detached mode is possible, but very painful. It's best to use an alternative tool in this case.

  • Your so called code as master approach is officially called code first Mar 16, 2011 at 19:26
  • 1
    @Berin, I want to clarify what you mean by "attached mode". I don't think that Entity Framework has a connection to the database open at all times. I believe EF works similar to NHibernate in this regard. Is this what you mean or do you mean something else? Do you have a link to documentation that explains this attached issue further? Mar 16, 2011 at 19:39
  • 1
    By attached, I mean all your interactions with the objects must take place within the using(EFConnection conn = new EFConnection) construct. If you attempt to stash that object somewhere for safe keeping so that you can do a quick update and save it again in a second using(...) statement, you'll have to think again. See msdn.microsoft.com/en-us/library/bb896271.aspx and msdn.microsoft.com/en-us/library/bb896248.aspx . Using EF 3.5 (which I had to use on the last version) isn't even that clean. Mar 16, 2011 at 20:03
  • Okay I get what you mean now. I just wanted to make sure people didn't take that to mean that there was always a connection to the database. You do have to have an object context that maintains the state of "attached" entities. Mar 16, 2011 at 20:26
  • 2
    This is not true. EF has a strong notion of detached entities. A detached entity must be reattached to its context before you can perform context related operations against it (such as updating it in the database). Also the metadata classes are only necessary if EF generates your entities for you. POCOs, IMO, are a much better way to use the EF. Using POCOs makes a lot of things much simpler, in particular testing.
    – Matt Greer
    Mar 16, 2011 at 23:52

One thing Microsoft isn't very good at is backward comparabilitycompatibility, especially when it comes to new technologies

Specifically EF1 (.net 3.5) is very different from EF4 (.net 4.0) - the same might occur for the next version.

I would wait for while and see how the technology matures.

In the mean time, consider using nHibernate - it's not equivalent, but it's mature and wildly used.

  • Simply ... the Domain Model is rarely a replica of the relational model in your database. So mapping some tables to a class and throwing it over the wire is just plain laziness. Tables might locally map into 1 object even though the database is is 3 different tables. Design the database intelligently.
  • 2nd this EF stuff cannot generate certain queries and you'll have to write them anyway.
  • 3rd The Domain Model doesn't map directly onto services .. One will only want to push the most minimal set of data over the wire as DTOs.. especially, if its going to be communicating with mobile apps.
  • 5Th test-ability ... Cannot create granular enough tests that will provide enough regression against code changes ... all to easy to
    break ...

I could write a 10 page diatribe. But, if you're just writing some throw away app for Company X .. who care then. But, if you're developing a software product ... you're going to have to be a lot more anal

  • this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Oct 9, 2013 at 21:28
  • EF doesn't generate domain objects. Those are DAO. You'll need to use the data from the object to create your domain object. You shouldn't be sending domain objects back from a service anyway, so create your thinner DTO from your domain objects before you return. EF should be able to generate most anything that you can express in LINQ. Database isn't part of a unit test, it's part of a functional test. That said, there are in memory mocks available for EF. Otherwise abstract your EF queries to a repository and then mock that instead. Aug 29, 2016 at 2:49
  • Yes, I concur .Rather, I am referring to patterns established by Martin Fowler and Carig Lairman. At the end of the day, I can't use CTEs,PARTITION BY or CROSS APPLY. I also, can't use a an IDataReader which allows one to keep the overhead of memory low. Also, when I run SQL Trace and see what EF sends across the wire I feel as if I might hurl ;-)
    – user104468
    Oct 12, 2017 at 20:45

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

The main points are :

  • Lack of lazy loading
  • Lack of persistence ignorance
  • The file format used for saving the entity model contains both visualization elements and the entity model itself causes merge problems in team environment.

Note that the above link is talking about EF1.

Also this link: http://ormeter.net/ shows that EF is not the best as compared to other ORMs in performance and LINQ support.

  • Bear in mind that this was posted when EF 1 was still newly released (or possibly still in beta). The situation is far better today with EF 4, and many of the issues raised in that vote of no confidence have been resolved. Mar 16, 2011 at 19:42
  • The last point still counts and is very significant.
    – M.Sameer
    Mar 16, 2011 at 23:43
  • 1
    The first EF version was 3.5. There haven't been four major versions of EF released.
    – Matt Greer
    Mar 16, 2011 at 23:53
  • 3
    @Matt that is correct. But the current version is called EF 4 in order to align with the rest of the .NET 4 versioning. Mar 17, 2011 at 12:33
  • 1
    Whether it's valid or not shouldn't affect the summary of the link, though. Votes will show if it's valid. :)
    – Adam Lear
    Sep 13, 2011 at 12:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.