What have your experiences been with Entity Framework?

Question

EF has been out for awhile now and I'm considering evaluating it - what have your experiences been?

I am interested in both web and desktop applications, and maybe some comparisons between EF and other ORM tools that you've used.

Learning curve is a factor since there is a team involved. Is this thing a bloated mess, or it is lean and sharp?

I heard that Microsoft is using this internally and in a big way, so that's a good sign. If you have any thoughts about how it might fit into the cloud-based future that MS seems to be spending their money on these days, that might also be interesting. After all, if this is something we might all eventually need to know, that would raise the priority level a notch or two.

Thanks a lot!

Answer 1

I personally hate EF. I LOVE LINQ-2-SQL. Here are my concrete warnings about EF:

1) EF doesn't support the "Contains" function. So, if you have a table of 10,000 'accounts', and you wanted to return some accounts that the user supplied a list of the ID's... you would have to download all 10,000 and do a for loop.

2) EF doesn't support lazy-loading: http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx

3) If you have a simple "Type" table, example AccountType... and you wanted to select all accounts from the Accounts table where AccountTypeID == 9, there is not a clean way of doing it in EF... EF would hide that field, and make you supply an instance of an AccountType class.

All of these issues are solved in L2S.

EDIT: Oh, you did ask "what are your experiences..." not just about issues. In my new job, they have a 205 table database, 600+ stored procedures, etc. I wanted to bridge the gap into the new world of programming... so I converted the DAL to a 1-1 "drag all tables in" version using EF. Here's what it looked like: Giant EDM

After only 1 week, I had to rip it out and replace it with L2S due to the issues I mentioned above, and a few more.

Answer 2

Well, I just finished implementing a complete system in EF, it was my first real experience with the EF in a production environment. The app is running now for about 45 days with 100's of users hitting it daily with no issues.

I think the largest thing is that you have to change your thinking. If you are thinking like a relational database ORM then you already have the wrong mindset. You need to think in terms of partial methods, objects and extentions. Once you get that basic mindset down things start to flow (and you rewrite a lot of code from when you first started).

Getting Help is rough

The other frustrating part of EF is that everywhere you go for help is full of L2S biggots who think they already know everything you need to do and keep trying to tell you to drop it and just use L2S... If I would have ASKED for how to do that in L2S then maybe their opinion would be valid...

EF Works Fine

The basic ability to generate objects that you can then extend through partial methods works well. I actually was pretty frustrated at the early stages because I kept trying to get things the way I would in a SQLCommand. Once you realize you can think in terms of what the business logic needs rather than how SQL works you can get a lot more done.

For example - I kept trying to do joins to get a list of things that were related by a specific FK for various tasks. Once I finally figured out that I can hand the entire where claus to the EF and let figure out how to get the data back to me quickly the code was actually much faster.

Includes stink

The Include syntax feels like a hack to me though. Having to use .Include("TableName.DetailTable") is UGLY. Maybe I am just spoiled by intellisense, but I hate that syntax.

On demand load

Master detail loads are also a bit ugly. If you don't want to include them you can always take their reference and see if it .IsLoaded then call .Load. Why? Can't the object do that for me? I ended up implementing an extention method on my objects that if I try to load a detail class that is not loaded it loads it on demand. Seems like that should have been built in to me.

Note: The detail load of a filtered recordset mentioned in the above post is not complicated, but is not obvious either. You can filter using Lambda expressions.

Do you EVER want to move the project?

Here is the big reason: Non vendor lock-in. If you EVER want to take that code to another database you CANNOT do it with Linq2SQL. There is no provider model. You may have a chance to move an EF system to another vendor. In my case the same project runs on SQL Server and VistaDB EF (Alpha) without code changes. So I can xcopy deploy it, or connect to a server as I choose at runtime.

Answer 3

After trialing EF for a new project (ASP.Net/ WCF) i found:

Querying to be very very easy to implment via LINQ. Most of the time the gnerated T-SQL was on the money.

Support for N-tier apps was majorly lacking.

Management of instances to the object context was equally painfull in n-layer, asp.net applications.

EF Designer was lacking some obvious features, was always diving into the XML.

Updates incur either costly database roundtrips or have crazily obscure methods to try and avoid them.

Performance hit was significantly noticable from an POCO & SP based n/tier app. This was expected but not to the extend we noticed. Even after compiling queiries.

The time we saved in development due to the ease of querying, was soon lost trying to do what was previously simple tasks.

As Brain touched on, refering to entity type or table name by string was majorly annoying and felt very messy, found myself writing wrappers to return these from a single point.

If you want to use a single layer app, then many of the issues we encoutered may not apply. But for us, we are keeping our eye out for V2 and hopefully some improvments.