What is the difference between Entity Framework and LINQ to SQL by .NET 4.0?

Question

I was checking 2nd edition of Professional ASP.NET MVC and realized EF replaced LINQ to SQL. I am familiar to LINQ to SQL from the first book but I know nothing about EF. Anyway while reading the code, it seems like nothing has changed except the name. Same old repository, same old functions.

I did a little research. I know LINQ is not limited to SQL. Also EF is not limited Microsoft-familiy SQL servers. In this 2 year old question people are not happy with EF, saying it's overcomplicated and all. But now I'm reading same code under EF name. Only classes are generated with ADO.NET Entity Model insted of LINQ to SQL. I have this buzzword crisis, can anybody clear out the fuss about shiny EF features since it's the de facto standart ORM now?

Answer 1

EF replaced LINQ to SQL

Lies.

---

Edit:

This question, and the many others like it on this site and the internet have a single common source.

EF users like to parade around one quote from Tim Mallalieu to try to rain on LinqToSql users.

In contrast, LinqToSql users do not parade around the contemporary Vote Of No Confidence thing in the face of the EF users.

What is it that EF users have against LinqToSql? Why must they defend their technology choice with such an ignorant campaign based on one sentence?

Answer 2

Latest EF is lot more robust, and you're not forced into a designer driven pseudo-ORM experience (or a morass of config if you tried to do it without the designer). Your model can be POCO objects now instead of some designer driven partial class mangled bs that's intrinsicly coupled with designer driven code, you can get away from the designer entirely without feeling like you're swimming upstream, and in general it just feels like they have listened to the community or actually tried to emulate existing, battle-tested solutions instead of making a version for the "Morts" or whatever L2Sql was supposed to be.

Answer 3

EF came of age with v4.0. Before that, it was a bit of a pain to use, and I didn't recommend it. Now my recommendation is that all new LINQ-to-DB code use EF4.

As far as new features go, the LINQ part is actually quite similar to LINQ to SQL. But it's quite a different architecture: EF4 acts as a LINQ provider to an (EF) ADO.NET provider which then wraps another ADO.NET provider. So there's new things like Entity SQL (which I don't use), and EF supporting different underlying ADO.NET providers (which I do use).

The XML modeling system that EF uses allows more powerful mapping abstractions, as well. One that I use regularly is having different tables with the same primary keys mapping to an entity inheritance relationship; from what I understand, the only way to do this in LINQ to SQL is via a "selector column" (though I never tried this in LINQ to SQL).

Answer 4

They are somewhat similar, and can be used in a very similar way, code-wise, but they have some important differences. Note that "LINQ" is not the same thing as "LINQ to SQL"; the EF also uses LINQ. Some notable differences are:

• LINQ to SQL is largely SQL Server only, not so much by design as by implementation. The EF is designed to support, and does support, multiple DBs, if you have a compatible ADO.NET provider.
• Out of the box, LINQ to SQL has a very poor story for DB metadata changes. You have to regenerate parts of your model from scratch, and you lose customizations.
• The EF supports model features like many-to-many relationships and inheritance. LINQ to SQL does not directly support these.
• In .NET 3.5, LINQ to SQL had much better support for SQL-Server-specific functionality than the EF. This is mostly not true in .NET 4; they're fairly similar in that respect.
• The EF lets you choose Model First, DB First, or Code First modeling. LINQ to SQL, out of the box, really only supports DB First.