Do you think it's advantageous to switch to Entity Framework? [closed]

Answer 1

I have to agree with Marc Gravell. Maybe when the next version of Entity Framework is released (.net 4.0 / VS2010) will there be an advantage to using EF, and by then it will probably be very different from the current version of EF.

Until then at least I will avoid EF like the plague for anything besides tests/experimental code that will never hit production.

The EF msdn forum is full of examples as to why EF is not ready for prime-time, but I there is one particular example that is a clear winner - what would normally be a simple five table query (10-15 lines of SQL) becomes >1500 lines of SQL when using EF and the EntityDataSource control:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3874607&SiteID=1

http://paste-it.net/public/q6ed5c2/

And as to the future of EF - with Microsoft's history of changing direction on big strategic things overnight, who knows if their current "strategic goal" with EF will come true a couple of years from now..? I for sure wouldn't bet on it. See:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4100399&SiteID=1#4107623

Answer 2

For the record, some hesitation about the future of LINQ to SQL has been expressed here:

Is LINQ to SQL DOA?

Has Microsoft really killed LINQ to SQL?

Answer 3

IMO, not at the moment.

It is clear (from recent announcements especially) that EF is in for some heavy revisions as the "thunderdome" scenario plays out between LINQ-to-SQL and EF. Whatever happens, EF (in a few years) will almost certainly look quite different to EF today. Or certainly "different enough" ;-p

As such, my view is: stick with simple. And simple is LINQ-to-SQL.

I don't see much benefit learning a notoriously complex system if I know it is going to change very soon.

And I'm 100% with you on LINQ-to-SQL ;-p

If I needed something more than LINQ-to-SQL right now, I'd look at NHibernate or maybe LLBLGen Pro.

(edit - as an update, my position has softened a little bit, here and here - but I'm still using LINQ-to-SQL as my primary tool; also - LINQ-to-SQL isn't quite dead yet ;-p).

Answer 4

LINQ to SQL doesn't seem to be an option unless you use SQL Server (or SQL Server compact), so that was reason enough for me to avoid it and use EF (I wanted to use PostgreSQL).

There are definitely enough things missing in v1 of EF that would make me hesitate to recommend it. It sounds like version 2 of the EF (when released) would be the first version that could be seriously recommended for switching over to.

Answer 5

Recently, i had to research which ORM project should use. At first - tried L2S. It wasn't bad at all, but it's already obsolete (MS won't support it anymore), that's why i started to check out L2E. I'm fine with generated code, but creating fake views, entities and mappings between them just to make stored procedure available not to fill all fields of entity was an overkill for me. And i wanted to separate my dataaccess layer, so - i had to map data from generated objects to ones i made.

It took me few hours of experimenting with NHibernate+Fluent NHibernate+LINQ to NHibernate
to stick with this combination.

Answer 6

I've completed a few MVC projects now in production with L2SQL under the hood and found it quite a joy to use. I'm now embarking on a new project and decided to write it using EF and L2EF given the previously cited articles proclaiming the death of L2SQL. After only a couple of days I've decided to go back to L2SQL. Simple things like having to set foreign keys for inserts using either the awful syntax shown below or uneccessary lookups have shocked me.

foo.Foreign_TypeReference.EntityKey = 
     new EntityKey("DataContextName.Foreign_Type", "Foreign_Type_Id", ForeignTypeId);

Rather than:

foo.Foreign_Type_Id = ForeignTypeId;

I don't think it will be that hard to port L2SQL to a future version of EF as L2SQL has a subset of the functionality (though better implemented). The few things that L2SQL has that L2EF doesn't, for example Single() and SingleOrDefault(), can be migrated to EF by creating a few extension methods. I think it will take far less time to get the system running using L2SQL and then port it over later when EF isn't so smelly.