Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as too broad by gnat, MichaelT, Kilian Foth, Ozz, Robert Harvey Oct 16 '13 at 17:20

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

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

6 Answers 6

up vote 5 down vote accepted

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... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4-1-release-candidate-available.aspx

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

share|improve this answer
    
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 at 7:19

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.

share|improve this answer
    
Your so called code as master approach is officially called code first –  Robert Koritnik Mar 16 '11 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? –  RationalGeek Mar 16 '11 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. –  Berin Loritsch Mar 16 '11 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. –  RationalGeek Mar 16 '11 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 '11 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.

share|improve this answer

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.
share|improve this answer
1  
This criticism is not valid for EF Code First but does apply to Model First and Database First. –  Alan Macdonald Oct 11 '13 at 23:36

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.

share|improve this answer
    
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. –  RationalGeek Mar 16 '11 at 19:42
    
The last point still counts and is very significant. –  M.Sameer Mar 16 '11 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 '11 at 23:53
2  
@Matt that is correct. But the current version is called EF 4 in order to align with the rest of the .NET 4 versioning. –  RationalGeek Mar 17 '11 at 12:33
    
I know it's been a while now since you posted this answer, but can you summarize the key points from that link in your answer please? Thanks! –  Anna Lear Sep 12 '11 at 21:41
  • 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

share|improve this answer
    
this post is rather hard to read (wall of text). Would you mind editing it into a better shape? –  gnat Oct 9 '13 at 21:28

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