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 classes, same old functions.

I did a little research. I know LINQ is not limited to SQL. Also EF is not limited Microsoft-family 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. Can anybody clear out the fuss about EF features since it's the de facto standart ORM now?

Answer 1

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.

Answer 2

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).