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

Question

I tested the 2nd edition of Professional ASP.NET MVC and implemented the replacement of EF with LINQ for SQL. I know LINQ to SQL from the first book, but I don't know anything about EF. Anyway, reading the code, it seems that nothing has changed except the name. The same old repository classes, the same old functions.

I did a little research. I know LINQ is not limited to SQL. In addition, EF is not limited to Microsoft SQL Server family. In this 2-year-old question, people are not happy with EF, saying it is too complicated and that’s it. But now I am reading the same code under the name EF. Only classes are created using the ADO.NET Entity Model built into LINQ to SQL. Can anyone eliminate the fuss about EF functions, since now it is standard ORM de facto?

Answer 1

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

• LINQ to SQL is basically SQL Server, not so much in design as in implementation. EF is designed to support and support multiple databases if you have a compatible ADO.NET provider.
• From the line, LINQ to SQL has a very poor history of changes to DB metadata. You need to restore the components of your model from scratch, and you lose the settings.
• EF supports model features such as many-to-many relationships and inheritance. LINQ to SQL does not directly support them.
• In .NET 3.5, LINQ to SQL has significantly improved SQL-Server functionality than EF. This basically does not apply to .NET 4; they are pretty similar in this regard.
• EF allows you to select a First, DB First or Code First model. LINQ to SQL, out of the box, really only supports DBs.

Answer 2

EF has reached the age of version 4.0. Before that, it was a little painful to use, and I did not recommend this. Now my recommendation is that all new LINQ-to-DB codes use EF4.

Regarding the new features, the LINQ part is actually very similar to LINQ to SQL. But this is a completely different architecture: EF4 acts as a LINQ provider for the ADO.NET (EF) provider, which then wraps another ADO.NET provider. So, there are such things as Entity SQL (which I do not use) and EF that support the different underlying ADO.NET providers (which I use).

The XML modeling system that EF uses allows for more powerful display abstractions . One of them, which I use regularly, has different tables with the same primary key mapping for the entity inheritance relationship; from what I understand, the only way to do this in LINQ to SQL is with a "selector column" (although I have never tried this in LINQ to SQL).

Answer 3

Difference between LINQ to SQL and Entity Framework:

LINQ to SQL:

• It works only with SQL Server database.
• It generates .dbml to maintain a relationship
• It does not support complex type.
• It cannot generate a database from a model.
• It allows you to display only one to one between entity classes and relational tables / views.
• It allows you to query data using a DataContext.
• It provides a closely related approach.
• It can only be used for rapid application development with SQL Server.

Entity Framework

• It can work with various databases, such as Oracle, DB2, MYSQL, SQL Server, etc.

• First it generates .edmx files. The relationship is maintained using 3 different .csdl, .msl and .ssdl files

• It supports a complex type.

• It can generate a database from a model.

• It allows one-to-one, one-to-many and many-to-many comparisons between Entity classes and relational tables / views

• It allows you to query data using EntitySQL, ObjectContext, DbContext.

• It provides a loosely coupled approach. Since his first approach to code allows you to use the Injection Dependency pattern, which makes it loosely coupled.

• It can be used to quickly develop applications using DBMSs such as SQL Server, Oracle, DB2 and MySQL, etc.

More details

Answer 4

The latter EF is much more reliable, and you are not forced to experience a design-based pseudo-ORM (or a configuration swamp if you try to do this without a designer). Now your model can be POCO objects, rather than partial bs classes partially processed by the designer, which together are connected with the designer-based encoder, you can completely leave the designer without feeling that you are floating upstream, and in general it’s just it looks like they listened to the community or were actually trying to emulate existing, battle-tested solutions, instead of making the version for "Morts" or any other L2Sql that should have been.