What is the difference between Entity Framework and LINQ to SQL by .NET 4.0?
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?
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.
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).
Difference between LINQ to SQL and Entity Framework:
LINQ to SQL:
- It only works with SQL Server Database.
- It generates a .dbml to maintain the relation
- It has not support for complex type.
- It cannot generate database from model.
- It allows only one to one mapping between the entity classes and the relational tables /views.
- It allows you to query data using DataContext.
- It provides a tightly coupled approach.
- It can be used for rapid application development only with SQL Server.
Entity Framework
It can works with various databases like Oracle, DB2, MYSQL, SQL Server etc.
It generates an .edmx files initially. The relation is maintained using 3 different files .csdl, .msl and .ssdl
It has support for complex type.
It can generate database from model.
It allows one-to-one, one-to-many & many-to-many mappings between the Entity classes and the relational tables /views
It allows you to query data using EntitySQL, ObjectContext, DbContext.
It provides a loosely coupled approach. Since its code first approach allow you to use Dependency Injection pattern which make it loosely coupled .
It can be used for rapid application development with RDBMS like SQL Server, Oracle, DB2 and MySQL etc.
More details
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.