Entity Framework vs LINQ to SQL

828

Maintenant que .NET v3.5 SP1 est sorti (avec VS2008 SP1), nous avons maintenant accès au framework d'entité .NET.

Ma question est la suivante. Lorsque vous essayez de décider entre l'utilisation de Entity Framework et LINQ to SQL comme ORM, quelle est la différence?

D'après ce que je comprends, l'Entity Framework (lorsqu'il est utilisé avec LINQ to Entities) est un «grand frère» de LINQ to SQL? Si tel est le cas - quels sont ses avantages? Que peut-il faire que LINQ to SQL ne peut pas faire seul?

.net entity-framework linq-to-sql

— Chris Roberts
source

138

Je pense que les réponses ci-dessous devraient être réexaminées car le temps écoulé depuis la sortie d'EF, de sorte que les nouveaux développeurs qui arrivent ici peuvent avoir une mauvaise impression. EF est devenu un outil GRAND et FACILE depuis sa première version. Vous venez de configurer la connexion à la base de données et c'est à peu près 90% de tout ce dont vous avez besoin. Développement très rapide, du point de vue expérimenté! De là - LINQ est votre meilleur ami. Il est hautement personnalisable, MVC adore ça, et pour les gens qui disent que c'est mauvais - Apprenez à l'utiliser en premier (et tenez-vous également sur LINQ)!

— graumanoz

10

Juste pour que ce soit clair - ce n'est pas comme si vous aviez le choix maintenant - MSFT a effectivement tué LINQ2SQL en faveur d'EF. Cependant, le fait que EF open source MSFT l'a aidé à aspirer moins et s'améliore définitivement. Mais pour tous ceux qui entrent dans EF - assurez-vous de comprendre qu'il y a encore beaucoup de bizarreries dans EF. J'en ai publié une - stackoverflow.com/questions/305092/…

— nikib3ro

4

@ kape123, (a) LINQ to SQL n'est pas "mort"; c'est toujours utilisable; (b) LINQ to SQL est la méthode d'accès aux données standard dans le développement de Windows Phone 8.

— Ryan Lundy du

9

@ user3308043, [citation nécessaire].

— Ryan Lundy

3

@Kyralessa - À partir de 2010 (avec la sortie de .NET4.0, la citation la plus récente que j'ai pu trouver), MS a reconnu que , bien que certains investissements puissent être faits dans LINQ2SQL, "la majeure partie de notre investissement global sera dans l'entité Cadre."

— kmote

483

LINQ to SQL prend uniquement en charge le mappage 1 à 1 des tables de base de données, des vues, des sprocs et des fonctions disponibles dans Microsoft SQL Server. C'est une excellente API à utiliser pour la construction d'un accès rapide aux données à des bases de données SQL Server relativement bien conçues. LINQ2SQL a été publié pour la première fois avec C # 3.0 et .Net Framework 3.5.

LINQ to Entities (ADO.Net Entity Framework) est une API ORM (Object Relational Mapper) qui permet une définition large des modèles de domaine objet et de leurs relations avec de nombreux fournisseurs de données ADO.Net différents. En tant que tel, vous pouvez mélanger et assortir un certain nombre de fournisseurs de bases de données, de serveurs d'applications ou de protocoles différents pour concevoir un mélange d'agrégats d'objets qui sont construits à partir d'une variété de tables, sources, services, etc. ADO.Net Framework a été publié avec le .Net Framework 3.5 SP1.

Ceci est un bon article d'introduction sur MSDN: Présentation de LINQ aux données relationnelles

— Kris
source

semble que vous utilisez LINQ to SQL pour interroger dans l'EF

— PositiveGuy

11

@CoffeeAddict, même si leur style est très similaire en utilisant les lambdas LINQ, chaque API a des fondements complètement différents. Par exemple, la façon dont LINQ2SQL génère des requêtes SQL permet d'utiliser des fonctions SQL, alors que L2E ne le fait pas, ou du moins pas à partir de 2008.

— Kris

2

L'approche orientée objet EF le rend vraiment facile et pratique à utiliser, peut être codé très rapidement, géré. Pour moi, c'est la meilleure façon d'accéder aux données.

— Antoine Pelletier

10

Cette réponse est obsolète. Linq to SQL prend désormais en charge le mappage one2many

— George Lanetz

201

Je pense que la réponse rapide et sale est que

LINQ to SQL est le moyen rapide et facile de le faire. Cela signifie que vous irez plus vite et que vous livrerez plus vite si vous travaillez sur quelque chose de plus petit.
Entity Framework est la manière la plus complète de le faire. Cela signifie que vous prendrez plus de temps à l'avance, que vous développerez plus lentement et que vous aurez plus de flexibilité si vous travaillez sur quelque chose de plus grand.

— Brad Tutterow
source

32

Vous aurez également tendance à écrire moins de lignes de code avec L2S pour accomplir la même chose qu'avec EF. Aucun chargement paresseux dans EF signifie que vous vérifiez toujours si quelque chose a été chargé ou non.

— Paul Mendoza

Brad, que proposeriez-vous pour un site de commerce électronique? Je veux dire que je ne vois rien d'autre que de simples CRUDs qui se passent là-bas ...

— PositiveGuy

2

@CoffeeAddict évidemment, le top 3 de la réponse la plus votée dit L2S pour simple CRUD

— IsmailS

11

@Banford Avec EF dans .NET 4.0, je pense que c'est mieux que L2S. Les fonctionnalités qui manquaient à EF dans 3.5 que L2S avait été ajoutées à EF dans .NET 4.0. Vos instructions LINQ maintenant dans EF dans .NET 4.0 vont ressembler à peu près à celles de L2S. EF vous offre des choses supplémentaires que vous pouvez faire maintenant en plus de ce que propose L2S.

— Paul Mendoza

40

Cette réponse a maintenant 5 ans et est assez dépassée. Entity Framework 6 est maintenant en version bêta et est beaucoup amélioré, inclut le chargement paresseux, le support enum, etc., etc.

— Tim

109

LINQ to SQL est-il vraiment mort? par Jonathan Allen pour InfoQ.com

Matt Warren décrit [LINQ to SQL] comme quelque chose qui "n'a même jamais été censé exister". Essentiellement, il était juste censé être un remplaçant pour les aider à développer LINQ jusqu'à ce que le véritable ORM soit prêt.

...

L'échelle d'Entity Framework lui a fait manquer la date limite .NET 3.5 / Visual Studio 2008. Il a été achevé à temps pour le malheureusement nommé ".NET 3.5 Service Pack 1", qui ressemblait plus à une version majeure qu'à un service pack.

...

Les développeurs n'aiment pas [ADO.NET Entity Framework] en raison de la complexité.

...

à partir de .NET 4.0, LINQ to Entities sera la solution d'accès aux données recommandée pour LINQ aux scénarios relationnels.

— Zack Peterson
source

56

En fait, nous n'aimons pas EF parce qu'il a un mauvais concepteur et est donc extrêmement, extrêmement bogué. Je ne l'ai jamais trouvé si complexe.

— BlueRaja - Danny Pflughoeft

12

BEAUCOUP de grands sites de commerce électronique utilisent LINQ to SQL. Exemples: Redbox, Stackoverflow, etc.

— PositiveGuy

14

Je connais BEAUCOUP de bons développeurs qui utilisent LINQ to SQL et disent que ces articles sont totalement exagérés. Je suis d'accord. LINQ to SQL a été utilisé dans de puissants .coms et l'est toujours.

— PositiveGuy

4

Oui, appeler .ToString () sur une propriété entière dans une requête L2EF ne doit pas provoquer d'exception.

— StingyJack

3

@ BlueRaja-DannyPflughoeft Est-ce toujours vrai après plus de 5 ans?

— Vikas Rana

94

Il y a un certain nombre de différences évidentes décrites dans cet article @lars publié, mais la réponse courte est:

L2S est étroitement couplé - propriété d'objet à un champ spécifique de la base de données ou plus correctement mappage d'objet à un schéma de base de données spécifique
L2S ne fonctionnera qu'avec SQL Server (pour autant que je sache)
EF permet de mapper une classe unique à plusieurs tables
EF gérera les relations MM
EF pourra cibler n'importe quel fournisseur de données ADO.NET

La prémisse initiale était que L2S était pour le développement rapide et EF pour les applications n-tier plus «d'entreprise», mais cela vend un peu L2S.

— JamesSugrue
source

13

Votre citation "L2S ne fonctionnera qu'avec SQL Server (pour autant que je sache)" doit être mise à jour: le projet open source "dblinq" remplace l'assembly LINQ to SQL par un qui peut parler à MySQL, PostgreSQL, Ingres, Firebird, SQLite. .. et Microsoft SQL (bien sûr).

— Contango

1

attendez ... donc EF ne crée pas d'objets DL étroitement couplés?

— PositiveGuy

7

oui, la prémisse d'origine que L2S n'est pas une solution d'entreprise n'est plus vraie. Je veux dire que StackOverflow fonctionne sur L2S et un tas d'autres .coms tels que Redbox, et bien d'autres.

— PositiveGuy

74

LINQ to SQL

Source de données homogène: SQL Server
Recommandé pour les petits projets uniquement lorsque la structure des données est bien conçue
Le mappage peut être modifié sans recompilation avec SqlMetal.exe
.dbml (langage de balisage de base de données)
Mappage un à un entre les tables et les classes
Prend en charge l' héritage TPH
Ne prend pas en charge les types complexes
Approche axée sur le stockage
Vue centrée sur la base de données d'une base de données
Créé par l'équipe C #
Améliorations soutenues mais non prévues

Cadre d'entité

Source de données Heterogeneus: prise en charge de nombreux fournisseurs de données
Recommandé pour tous les nouveaux projets sauf:
- petits (LINQ to SQL)
- lorsque la source de données est un fichier plat (ADO.NET)
Le mappage peut être modifié sans recompilation lors de la définition du modèle et des fichiers de mappage Processus d'artefact de métadonnées à copier dans le répertoire de sortie
.edmx (Entity Data Model) qui contient:
- SSDL (Storage Schema Definition Language)
- CSDL (Conceptual Schema Definition Language)
- MSL (Mapping Specification Language)
Mappages un-à-un, un-à-plusieurs, plusieurs-à-un entre les tables et les classes
Prend en charge l'héritage:
- TPH (table par hiérarchie)
- TPT (table par type)
- TPC (table par classe de béton)
Prend en charge les types complexes
Approches Code-First, Model-First, Storage-First
Vue centrée sur l'application d'une base de données
Créé par l'équipe SQL Server
L'avenir des API de données Microsoft

Voir également:

— Ryszard Dżegan
source

6

Ceci est la réponse la plus récente et la plus détaillée.

— ErTR

2

Entity Framework n'utilise- t-il pas LINQ to SQL lorsque, par exemple, vous écrivez un dbSet<Orders>.Where()...ToList()? Je pense qu'il est trompeur d'avoir Entity Framework opposé de LINQ à SQL.

— Don Cheadle

4

@mmcrae EF n'utilise L2S, les deux sont des fournisseurs de LINQ aux bases de données sous - jacentes. Si vous l'interprétez comme Linq-to-a-database, similaire à linq-to-objects et linq-to-xml, alors oui, les deux sont similaires dans linq-to-a-database. Mais non, EF n'utilise pas L2S (ou vice versa). Deux outils complètement séparés.

— Maarten

4

"Recommandé pour tous les nouveaux projets sauf ... les petits" Je ne suis pas d'accord. Code First est un moyen extrêmement rapide de démarrer avec de petits projets. A part ça, bonne mise à jour de cette question.

— DrewJordan

51

Mon expérience avec Entity Framework a été loin d'être exceptionnelle. Tout d'abord, vous devez hériter des classes de base EF, alors dites au revoir aux POCO. Votre design devra être autour de l'EF. Avec LinqtoSQL, je pouvais utiliser mes objets métier existants. De plus, il n'y a pas de chargement paresseux, vous devez l'implémenter vous-même. Il existe des solutions pour utiliser les POCO et le chargement paresseux, mais ils existent à mon humble avis car EF n'est pas encore prêt. J'ai l'intention d'y revenir après 4.0

— Jiyosub
source

7

Le manque de prise en charge de POCO est la principale raison pour laquelle j'ai choisi LINQ to SQL sur Entity Framework. Je reverrai peut-être EF lorsqu'ils l'intégreront dans la prochaine version, comme ils le promettent. Il existe des projets supplémentaires qui font des POCO pour EF, mais pas assez proprement.

— Joseph Ferris

27

Dans le cas où quelqu'un (comme moi) ne sait pas ce que POCO signifie: Plain Old CLR Object

— CBono

4

Je ne vois vraiment pas quel est le gros problème de ne pas prendre en charge les POCO ... c'est un niveau supplémentaire de gars de l'abstraction. Créez une fabrique, injectez le référentiel de données et construisez-y vos POCO. C'est probablement une bonne idée de toute façon.

— EightyOne Unite du

3

J'entends que POCO est possible dans EF 4

— PositiveGuy

8

La prise en charge de POCO est disponible de nos jours et l'héritage n'est plus une exigence pour les classes d'entités @CoffeeAddict POCO est juste un objet simple sans recours à un cadre spécifique et est une partie importante des modèles de cadre d'entité modernes

— Chris McGrath

46

J'ai trouvé une très bonne réponse ici qui explique quand utiliser quoi en termes simples:

La règle de base pour quel cadre utiliser est de savoir comment planifier la modification de vos données dans votre couche de présentation.

Linq-To-Sql - utilisez ce cadre si vous prévoyez de modifier une relation un-à-un de vos données dans votre couche de présentation. Cela signifie que vous ne prévoyez pas de combiner les données de plusieurs tables dans une seule vue ou page.

Entity Framework - utilisez ce cadre si vous prévoyez de combiner les données de plusieurs tables dans votre vue ou page. Pour rendre cela plus clair, les termes ci-dessus sont spécifiques aux données qui seront manipulées dans votre vue ou votre page, pas seulement affichées. C'est important à comprendre.

Avec Entity Framework, vous pouvez «fusionner» les données déposées ensemble pour les présenter à la couche de présentation sous une forme modifiable, puis lorsque ce formulaire sera soumis, EF saura mettre à jour TOUTES les données des différentes tables.

Il existe probablement des raisons plus précises de choisir EF plutôt que L2S, mais ce serait probablement la plus facile à comprendre. L2S n'a pas la capacité de fusionner les données pour la présentation de la vue.

— Nawaz
source

36

Mon impression est que votre base de données est assez énorme ou très mal conçue si Linq2Sql ne correspond pas à vos besoins. J'ai environ 10 sites Web à la fois plus grands et plus petits utilisant tous Linq2Sql. J'ai regardé le framework Entity plusieurs fois mais je ne trouve pas de bonne raison de l'utiliser sur Linq2Sql. Cela dit, j'essaie d'utiliser mes bases de données comme modèle, donc j'ai déjà une correspondance 1 à 1 entre le modèle et la base de données.

À mon travail actuel, nous avons une base de données avec plus de 200 tables. Une ancienne base de données avec beaucoup de mauvaises solutions, donc je pouvais voir les avantages d'Entity Framework sur Linq2Sql mais je préférerais quand même repenser la base de données car la base de données est le moteur de l'application et si la base de données est mal conçue et lente, alors mon application sera également lent. L'utilisation du framework Entity sur une telle base de données semble être un quickfix pour masquer le mauvais modèle, mais cela ne pourrait jamais masquer les mauvaises performances que vous obtenez d'une telle base de données.

— terjetyl
source

1

Vous manquez le point - même avec de petites bases de données, vous voudrez peut-être quelque chose de différent d'une relation 1: 1 entre les tables de base de données et les objets code / domaine. Tout dépend de la quantité d'abstraction que vous voulez dans les objets bus / domaine.

— alchimique

18

Je l'ai réalisé :) Aujourd'hui, j'aime coder manuellement mes entités commerciales. J'utilise toujours Linq2sql mais uniquement dans mes référentiels où j'obtiens des données en utilisant Linq2sql et convertis les entités linq2sql en mes entités commerciales personnalisées. Peut-être un peu plus de travail que d'utiliser un or-mapper mais j'aime toujours garder ma couche métier exempte de tout code spécifique au mappeur OR.

— terjetyl

25

Vous pouvez trouver une bonne comparaison ici:

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

— Omer K
source

2

Certaines choses dans la réponse ne sont pas correctes. Un EDMX n'est pas requis si vous utilisez Code First. Et je ne comprends pas comment DI entre en jeu lorsque vous utilisez Code First.

— Maarten

1

De plus, Linq to SQL peut très bien remplir une base de données à partir des classes de modèle. Je ne sais pas s'il peut également générer la base de données elle-même, mais la génération du schéma et des tables relève de Linq aux capacités de SQL.

— Tom Lint

Merci pour la réponse, je pense que l'on peut utiliser sqlmetal.exe docs.microsoft.com/en-us/dotnet/framework/tools/… pour générer du code / mappage à partir de la base de données lors de l'utilisationLinq to SQL

— Vinod Srivastav

23

Les réponses ici ont couvert de nombreuses différences entre Linq2Sql et EF, mais il y a un point clé qui n'a pas reçu beaucoup d'attention: Linq2Sql prend uniquement en charge SQL Server tandis qu'EF a des fournisseurs pour les SGBDR suivants:

Fourni par Microsoft:

Pilotes ADO.NET pour SQL Server, OBDC et OLE DB

Via des fournisseurs tiers:

MySQL
Oracle
DB2
VistaDB
SQLite
PostgreSQL
Informix
U2
Sybase
Synergex
Oiseau de feu
Npgsql

pour n'en nommer que quelques-uns.

Cela fait d'EF une abstraction de programmation puissante sur votre magasin de données relationnelles, ce qui signifie que les développeurs ont un modèle de programmation cohérent avec lequel travailler, quel que soit le magasin de données sous-jacent. Cela pourrait être très utile dans les situations où vous développez un produit dont vous voulez vous assurer qu'il fonctionnera avec une large gamme de SGBDR courants.

Une autre situation où cette abstraction est utile est lorsque vous faites partie d'une équipe de développement qui travaille avec un certain nombre de clients différents, ou différentes unités commerciales au sein d'une organisation, et que vous souhaitez améliorer la productivité des développeurs en réduisant le nombre de SGBDR qu'ils doivent devenir familiariser avec afin de prendre en charge une gamme d'applications différentes au-dessus de différents SGBDR.

— saille
source

15

J'ai constaté que je ne pouvais pas utiliser plusieurs bases de données dans le même modèle de base de données lors de l'utilisation d'EF. Mais dans linq2sql, je pouvais juste en préfixant les noms de schéma avec les noms de base de données.

C'est l'une des raisons pour lesquelles j'ai commencé à travailler avec linq2sql. Je ne sais pas si EF a encore autorisé cette fonctionnalité, mais je me souviens avoir lu qu'il était destiné à ce qu'il ne le permette pas.

— Banford
source

12

Si votre base de données est simple et directe, LINQ to SQL fera l'affaire. Si vous avez besoin d'entités logiques / abstraites au-dessus de vos tables, optez pour Entity Framework.

— vintana
source

4

Entity Framework permet une couche d'abstraction en haut de la base de données. Le problème avec de nombreux mappeurs OR aujourd'hui (à mon avis) est qu'ils fournissent un mappage 1 à 1 entre les tables et les classes. Le modèle de base de données ne reflète pas toujours la façon dont nous y pensons en termes de modèle commercial.

— senfo

Manqué d'espace. Quoi qu'il en soit, sur la base de ce que j'ai dit ci-dessus, je dirais que votre réponse n'est pas complète.

— senfo

7

Je pense que c'est vraiment un mauvais conseil. L2S est bon quelle que soit la simplicité ou la complexité de votre base de données. Le vrai piège n'est pas d'avoir une séparation appropriée des préoccupations. Si vous essayez de fusionner votre couche métier et votre couche d'accès aux données, et utilisez vos objets Linqed up pour tout, alors vous trouverez la limitation L2S. Mais c'est un problème avec une conception trop simpliste et monolithique. L2S fait un excellent DAL, et si vous considérez l'interrogation et la persistance comme une préoccupation distincte de vos règles métier, vous vous épargnerez beaucoup de problèmes dans de nombreux domaines à long terme.

— mattmc3

1

cela ne me dit rien. Qu'est-ce qui est simple à vos yeux?

— PositiveGuy

1

et que voulez-vous dire par exemple pour un besoin de "logique / abstrait". Oui, je sais ce qu'est l'abstraction, mais un exemple dans votre contexte, s'il vous plaît ... pour m'expliquer exactement ce que vous dites ... décrivez-le, ne me donnez pas juste de l'argot général ... tout est relatif à l'orateur ces mots, donc je n'ai aucune idée de ce que VOUS entendez par là.

— PositiveGuy

8

Aucun des deux ne prend encore en charge les types de données SQL 2008 uniques. La différence de mon point de vue est qu'Entity a encore une chance de construire un modèle autour de mon type de données géographiques dans une version future, et Linq to SQL, étant abandonné, ne le sera jamais.

Je me demande ce qui se passe avec nHibernate ou OpenAccess ...

— John Dunagan
source

3

SQL Server 2008 Spatial datatypes (Open Geospatial Consortium OGS) pris en charge à partir d'Entity Framework 5. D'autres fournisseurs (Devart pour Oracle) sont également pris en charge. Voir msdn.microsoft.com/en-us/data/dn194325 .

— subsci

6

Je pense que si vous avez besoin de développer quelque chose de rapide sans aucune chose étrange au milieu, et vous avez besoin de la possibilité d'avoir des entités représentant vos tables:

Linq2Sql peut être un bon allié, l'utiliser avec LinQ libère un excellent timing de développement.

— MRFerocius
source

4

"Pas d'étranges choses au milieu", ok qu'est-ce que tu veux dire par là. Exemple d'une "chose étrange au milieu"

— PositiveGuy

Ce serait bien de modifier ou de supprimer cette réponse, elle n'est plus utile pour le développement moderne et peut amener les gens sur la mauvaise voie.

— Giulio Caccin

6

Je travaille pour un client qui a un grand projet qui utilise Linq-to-SQL. Lorsque le projet a démarré, c'était le choix évident, car Entity Framework manquait à l'époque de fonctionnalités majeures et les performances de Linq-to-SQL étaient bien meilleures.

Maintenant, EF a évolué et Linq-to-SQL manque de prise en charge asynchrone, ce qui est idéal pour les services hautement évolutifs. Nous avons parfois plus de 100 requêtes par seconde et malgré l'optimisation de nos bases de données, la plupart des requêtes prennent encore plusieurs millisecondes. En raison des appels de base de données synchrones, le thread est bloqué et n'est pas disponible pour les autres demandes.

Nous envisageons de passer à Entity Framework, uniquement pour cette fonctionnalité. Il est dommage que Microsoft n'ait pas implémenté la prise en charge asynchrone dans Linq-to-SQL (ou open source, afin que la communauté puisse le faire).

Addendum décembre 2018: Microsoft évolue vers .NET Core et Linq-2-SQL n'est pas pris en charge sur .NET Core, vous devez donc passer à EF pour vous assurer de pouvoir migrer vers EF.Core à l'avenir.

Il existe également d'autres options à considérer, telles que LLBLGen . C'est une solution ORM mature qui existe déjà depuis longtemps et qui s'est avérée plus pérenne que les solutions de données MS (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).

— Ramon de Klein
source

2

Linq-to-SQL

C'est un fournisseur qui prend en charge SQL Server uniquement. Il s'agit d'une technologie de mappage pour mapper les tables de base de données SQL Server aux objets .NET. Est la première tentative de Microsoft pour un ORM - Object-Relational Mapper.

Linq-to-Entities

Est la même idée, mais en utilisant Entity Framework en arrière-plan, comme l'ORM - encore une fois de Microsoft, il prend en charge plusieurs bases de données.

Selon mon expérience personnelle, Ef est meilleur (si vous n'avez aucune idée de SQL) les performances dans LINQ sont un peu plus rapides que dans le langage EF raison LINQ écrit en lambda.

— Umang Patwa
source