Question Entity Framework vs LINQ à SQL


Maintenant que .NET v3.5 SP1 a été publié (avec VS2008 SP1), nous avons maintenant accès à l'infrastructure de l'entité .NET.

Ma question est la suivante. Lorsque vous essayez de choisir entre utiliser Entity Framework et LINQ to SQL comme ORM, quelle est la différence?

La façon dont je le comprends, l'Entity Framework (lorsqu'il est utilisé avec LINQ to Entities) est un «grand frère» à LINQ to SQL? Si c'est le cas, quels sont les avantages? Que peut-il faire que LINQ to SQL ne puisse pas faire seul?


750
2017-08-12 11:04


origine


Réponses:


LINQ to SQL prend uniquement en charge le mappage 1 à 1 des tables, vues, sprocs et fonctions de base de données disponibles dans Microsoft SQL Server. C'est une API géniale à utiliser pour la construction rapide d'accès aux données vers 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 large définition des modèles de domaine objet et de leurs relations avec de nombreux fournisseurs de données ADO.Net. En tant que tel, vous pouvez mélanger et faire correspondre un certain nombre de fournisseurs de bases de données, de serveurs d'applications ou de protocoles différents pour concevoir un ensemble d'objets constitués d'une variété de tables, sources, services, etc. ADO.Net Framework a été publié avec le .Net Framework 3.5 SP1.

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


442
2017-09-21 03:22



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

  • LINQ to SQL est la manière rapide et facile de le faire. Cela signifie que vous allez aller plus vite, et livrer plus rapidement si vous travaillez sur quelque chose de plus petit.
  • Entity Framework est la manière absolue de le faire. Cela signifie que vous prendrez plus de temps à l'avance, que vous vous développerez plus lentement et aurez plus de flexibilité si vous travaillez sur quelque chose de plus grand.

188
2017-08-12 16:00



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 jamais été supposé exister". Essentiellement, c'était juste supposé être stand-in pour les aider à développer LINQ jusqu'à ce que le vrai ORM soit prêt.

...

L'échelle d'Entity Framework l'a fait manquer la date limite .NET 3.5 / Visual Studio 2008. Il a été achevé à temps pour le ".NET 3.5 Service Pack 1", qui s'apparentait 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.


103
2017-11-03 15:53



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

  • L2S est étroitement couplé - propriété d'objet à un champ spécifique de base de données ou plus correctement le 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 seule classe à plusieurs tables
  • EF gérera les relations M-M
  • EF aura la possibilité de cibler n'importe quel fournisseur de données ADO.NET

La prémisse initiale était L2S est pour le développement rapide, et EF pour plus d'applications "n-tier" d'entreprise, mais c'est vendre L2S un peu court.


85
2017-08-12 11:15



LINQ à 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. Les soutiens TPH héritage
  7. Ne supporte pas les types complexes
  8. Approche du stockage d'abord
  9. Vue centrée sur la base de données d'une base de données
  10. Créé par l'équipe C #
  11. Supporte mais pas d'autres améliorations prévues

Cadre d'entité

  1. Source de données Heterogeneus: Soutenir de nombreux fournisseurs de données
  2. Recommandé pour tous les nouveaux projets sauf:
    • les plus 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 des fichiers de modèle et de mappage Processus d'artefact des métadonnées à copier dans le répertoire de sortie
  4. .edmx (Entity Data Model) qui contient:
    • SSDL (Langage de définition du schéma de stockage)
    • CSDL (langage de définition de schéma conceptuel)
    • MSL (langage de spécification de mappage)
  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. Priorité au code, modèle premier, approche du stockage d'abord
  9. Vue centrée sur l'application d'une base de données
  10. Créé par l'équipe SQL Server
  11. Futur des API de données Microsoft

Voir également:


55
2018-04-21 08:26



Mon expérience avec Entity Framework a été moins qu'élevée. 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 pourrais 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 y a un certain nombre de solutions pour utiliser les POCO et le chargement paresseux, mais elles existent à mon humble avis car EF n'est pas encore prêt. Je prévois d'y revenir après 4.0


49
2017-12-08 03:50



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

La règle de base pour laquelle le framework à utiliser est comment planifier   éditer vos données dans votre couche de présentation.

  • Linq-To-Sql - utiliser ce framework si vous envisagez d'éditer un one-to-one   relation de vos données dans votre couche de présentation. Ce qui veut dire   ne prévoyez pas de combiner les données de plus d'une table dans une même vue   ou page.

  • Cadre d'entité - utiliser ce cadre si vous prévoyez   combiner les données de plus d'une table dans votre vue ou page. Faire   plus clair, les termes ci-dessus sont spécifiques aux données qui seront   manipulé dans votre vue ou page, pas seulement affiché. C'est   important de comprendre.

Avec Entity Framework, vous êtes en mesure de "fusionner" des données présentées ensemble   présenter à la couche de présentation dans une forme modifiable, puis   lorsque ce formulaire est soumis, EF saura comment mettre à jour TOUTES les données   des différentes tables.

Il y a probablement des raisons plus précises de choisir EF par rapport à L2S, mais   ce serait probablement le plus facile à comprendre. L2S ne fait pas   avoir la capacité de fusionner des données pour la présentation de vue.


44
2018-03-23 15:52



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 plus grands et plus petits tout en utilisant Linq2Sql. J'ai regardé et le cadre d'Entité plusieurs fois mais je ne peux pas trouver une bonne raison de l'employer au-dessus de 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 l'avantage d'Entity Framework sur Linq2Sql mais je préférerais refaire la base de données puisque 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 d'Entity Framework sur une telle base de données semble être un correctif pour masquer le mauvais modèle, mais il ne pourrait jamais masquer les mauvaises performances que vous obtenez d'une telle base de données.


34
2017-11-21 19:52



Vous pouvez trouver une bonne comparaison ici:

enter image description here

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

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


21
2017-08-31 20:07