Entity Framework vs LINQ to SQL

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?

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

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.

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.

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.

LINQ to SQL

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

Cadre d'entité

1. Source de données Heterogeneus: prise en charge de nombreux fournisseurs de données
2. Recommandé pour tous les nouveaux projets sauf:
   • petits (LINQ to SQL)
   • lorsque la source de données est un fichier plat (ADO.NET)
3. 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
4. .edmx (Entity Data Model) qui contient:
   • SSDL (Storage Schema Definition Language)
   • CSDL (Conceptual Schema Definition Language)
   • MSL (Mapping Specification Language)
5. Mappages un-à-un, un-à-plusieurs, plusieurs-à-un entre les tables et les classes
6. Prend en charge l'héritage:
   • TPH (table par hiérarchie)
   • TPT (table par type)
   • TPC (table par classe de béton)
7. Prend en charge les types complexes
8. Approches Code-First, Model-First, Storage-First
9. Vue centrée sur l'application d'une base de données
10. Créé par l'équipe SQL Server
11. L'avenir des API de données Microsoft

Voir également:

• LINQ To SQL Vs Entity Framework
• Différence entre LINQ to SQL et Entity Framework
• Entity Framework vs LINQ TO SQL

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

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.

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.

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

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.

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.

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.

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

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.

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

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.