Question

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

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

La façon dont je le comprends, le Cadre de l'Entité (lorsqu'il est utilisé avec LINQ to entities) est un "big brother" de LINQ to SQL?Si c'est le cas quels avantages a-t-elle?Que peut-il faire que LINQ to SQL ne peut pas le faire sur son propre?

Était-ce utile?

La solution

LINQ to SQL prend en charge uniquement 1 à 1 de cartographie de base de données de tables, de vues, sprocs et les fonctions disponibles dans Microsoft SQL Server.C'est un grand API à utiliser pour rapide d'accès aux données de construction relativement bien conçu bases de données SQL Server.LINQ2SQL a d'abord été publié avec C# 3.0 et .Net Framework 3.5.

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

C'est un bon article d'introduction sur MSDN:L'introduction de LINQ to de Données Relationnelles

Autres conseils

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

  • LINQ to SQL est rapide et facile à faire.Cela signifie que vous obtiendrez en allant plus vite, et de livrer plus rapidement si vous travaillez sur quelque chose de plus petit.
  • Entity Framework est le tout-out, no-holds-barred façon de le faire.Cela signifie que vous prenez plus de temps, de développer plus lentement, et avoir plus de flexibilité si vous travaillez sur quelque chose de plus grand.

Est LINQ to SQL Réellement 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, c'était juste censé être en stand-in pour les aider à développer LINQ jusqu'à ce que le réel ORM était prêt.

...

L'échelle de l'Entity Framework a provoqué pour la louper .NET 3.5 et Visual Studio 2008, date limite.Il a été achevé à temps pour l'malheureusement nommé ".NET 3.5 Service Pack 1", qui était plus comme une version majeure d'un service pack.

...

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

...

comme de .NET 4.0, LINQ to entities sera recommandé solution d'accès aux données pour LINQ to scénarios relationnels.

Il y a un certain nombre de différences évidentes contenues dans l'article @lars posté, mais la réponse courte est:

  • L2S est étroitement associé - propriété de l'objet spécifique du champ de base de données ou, plus correctement, objet de la cartographie à un schéma de base de données
  • L2S ne fonctionne qu'avec SQL Server (autant que je sache)
  • EF permet de cartographier une seule classe à plusieurs tables
  • EF poignée M-M relations
  • EF ont la capacité à cibler ADO.NET fournisseur de données

La prémisse originale a été L2S est pour un Développement Rapide et EF pour plus d' "enterprisey" des applications n-tier, mais c'est la vente de L2S un peu court.

LINQ to SQL

  1. Homogène source de données:SQL Server
  2. Recommandé pour les petits projets où la structure de données est bien conçu
  3. La cartographie peut être modifié sans recompilling avec SqlMetal.exe
  4. .dbml de données (Langage de Balisage)
  5. One-to-one mapping entre les tables et les classes
  6. Prend en charge TPH l'héritage
  7. Ne prend pas en charge les types complexes
  8. Stockage-première approche
  9. Base de données centrée sur la vue d'une base de données
  10. Créé par l'équipe C#
  11. Prise en charge, mais pas d'autres améliorations destinées

Entity Framework

  1. Heterogeneus source de données: En charge de nombreux fournisseurs de données
  2. Recommandé pour tous les nouveaux projets, à l'exception:
    • les petits (LINQ to SQL)
    • lorsque la source de données est un fichier plat (ADO.NET)
  3. La cartographie peut être modifié sans recompilling lors de la configuration du modèle et des fichiers de mappage des Métadonnées Artefact Processus de Copie vers le Répertoire De Sortie
  4. .edmx (Entity Data Model) qui contient:
    • Trois laboratoires (Stockage Langage de Définition de Schéma)
    • CSDL (Conceptual Schema Definition Language)
    • MSL (Cartographie Langage de Spécification)
  5. Un-à-un, un-à-plusieurs, plusieurs-à-un les mappages entre les tables et les classes
  6. Prend en charge l'héritage:
    • TPH (une Table Par Hiérarchie)
    • TPT (une Table Par Type)
    • TPC (une Table Par Classe Concrète)
  7. Prend en charge les types complexes
  8. Code-tout d'abord, le Modèle de la première, de Stockage-premières approches
  9. Centrée sur les applications vue d'une base de données
  10. Créé par l'équipe SQL Server
  11. L'avenir de Microsoft Api de Données

Voir aussi:

Mon expérience avec Entity Framework a été moins que stellaire.Tout d'abord, vous devez hériter de l'EF classes de base, afin de dire au revoir à POCOs.Votre dessin devra être autour de l'EF.Avec LinqtoSQL je pouvais utiliser mon business objects.En outre, il n'y a pas de chargement paresseux, vous avez à mettre en œuvre vous-même.Il y a quelques solutions pour utiliser Poco et le chargement paresseux, mais ils existent, à mon humble avis parce que EF n'est pas encore prête.J'ai l'intention de revenir après 4.0

J'ai trouvé une très bonne réponse ici ce qui explique quand utiliser que dans des mots simples:

La règle de base pour le cadre de base à utiliser est la façon de planifier sur modification de vos données dans la couche de présentation.

  • Linq-To-Sql - l'utilisation de ce cadre si vous prévoyez sur l'édition d'un one-to-one relation de vos données dans la couche de présentation.Ce qui signifie que vous ne comptez pas sur la combinaison de données provenant de plus d'une table dans une vue ou de la page.

  • Entity Framework - l'utilisation de ce cadre si vous prévoyez sur en combinant des données provenant de plus d'une table dans votre vue ou de la page.Pour faire plus de clarté, les termes ci-dessus sont spécifiques à des données qui seront manipulés dans votre vue ou de la page, pas seulement affiche.C'est important de le comprendre.

Avec Entity Framework, vous êtes en mesure de les "fusionner", déposé données de présenter à la couche de présentation dans un format éditable, et puis lorsque le formulaire est soumis, EF savoir comment mettre à jour TOUTES les données les divers tableaux.

Il y a probablement plus exacte raisons de choisir EF cours de L2, mais ce serait probablement le plus simple à comprendre.L2S n' ont la capacité de fusionner les données pour voir la présentation.

Mon impression est que votre base de données est assez énorme mal ou très mal conçu si Linq2Sql ne répondent pas à vos besoins.J'ai autour de 10 sites web à la fois plus vaste et de plus en plus petits à l'aide de Linq2Sql.J'ai regardé et Entity framework plusieurs fois, mais je ne peux pas trouver une bonne raison de l'utiliser sur Linq2Sql.Cela dit j'essaie d'utiliser mes bases de données en tant que modèle, de sorte que j'ai déjà un 1 à 1 mapping entre le modèle et la base de données.

À mon travail actuel, nous avons une base de données avec plus de 200 tableaux.Une ancienne base de données avec beaucoup de mauvaises solutions alors là, j'ai pu voir l'intérêt de l'Entité Cadre de Linq2Sql encore, mais je préfère à la refonte de la base de données depuis la base de données est le moteur de l'application, et si la base de données est mal conçu et lent, puis mon application sera aussi lent.À l'aide de Entity framework sur cette base de données semble comme un quickfix pour dissimuler le mauvais modèle, mais il n'a jamais pu dissimuler la mauvaise performance que vous obtenez à partir d'une telle base de données.

Les réponses données ici ont couvert un grand nombre de différences entre Linq2Sql et de l'EF, mais il y a un point essentiel qui n'a pas été donné beaucoup d'attention:Linq2Sql prend uniquement en charge SQL Server alors que EF a des fournisseurs pour la suite du SGBDR:

Fourni par Microsoft:

  • ADO.NET pilotes pour SQL Server, ODBC et OLE DB

L'intermédiaire de tiers fournisseurs:

  • MySQL
  • Oracle
  • DB2
  • VistaDB
  • SQLite
  • PostgreSQL
  • Informix
  • U2
  • Sybase
  • Synergex
  • Firebird
  • Npgsql

pour n'en nommer que quelques-unes.

Cela rend EF un puissant outil de programmation d'abstraction au-dessus de votre magasin de données relationnelles, sens développeurs ont un modèle de programmation cohérent de travailler avec quel que soit le sous-jacent banque de données.Cela pourrait être très utile dans les situations où vous êtes en train de développer un produit que vous voulez vous assurer que vont interagir avec un large éventail de communes du SGBDR.

Une autre situation où l'abstraction est utile lorsque vous faites partie d'une équipe de développement qui travaille avec un certain nombre de différents clients, ou les différentes unités d'affaires au sein d'une organisation, et vous souhaitez améliorer la productivité des développeurs en réduisant le nombre de SGBDR est qu'ils ont à devenir familier avec afin de soutenir un éventail d'applications différentes sur le dessus de différentes du SGBDR.

J'ai trouvé 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 de l'EF.Mais dans linq2sql je pouvais juste en préfixant le schéma de noms avec les noms de base de données.

C'était l'une des raisons que j'ai d'abord commencé à travailler avec linq2sql.Je ne sais pas si EF a encore permis cette fonctionnalité, mais je me souviens avoir lu qu'il était prévu pour elle de ne pas permettre cela.

Si votre base de données est simple et rapide, LINQ to SQL va faire.Si vous avez besoin de logique/entités abstraites sur le dessus de vos tables, puis aller pour Entity Framework.

Ne le prend en charge l'unique SQL 2008 les types de données.La différence de mon point de vue est que l'Entité a encore une chance de construire un modèle autour de mon géographique, le type de données dans une version future, et Linq to SQL, abandonnée, ne le sera jamais.

Me demande qu'est-ce qu'nHibernate, ou OpenAccess...

Je pense que si vous avez besoin de développer quelque chose de rapide avec pas de choses Étranges dans le milieu, et vous avez besoin de la facilité d'avoir des entités représentant vos tables:

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

Je travaille pour un client qui a un gros projet qui est à l'aide de Linq-to-SQL.Lorsque le projet a commencé c'était le choix évident, parce que Entity Framework manquait quelques grands traits de l'époque et de la performance de Linq-to-SQL a été beaucoup mieux.

Maintenant EF a évolué et Linq-to-SQL manque asynchrone de soutien, ce qui est excellent et très évolutifs des services.Nous avons+ de 100 requêtes par seconde, parfois, et malgré le fait que nous avons optimisé nos bases de données, la plupart des requêtes prendre quelques millisecondes pour terminer.En raison de la base de données synchrone appels, le thread est bloqué et ne sont pas disponibles pour les autres demandes.

Nous pensons passer à Entity Framework, uniquement pour cette fonction.C'est dommage que Microsoft n'a pas mise en œuvre asynchrone de la prise en charge de Linq-to-SQL (ou open-source, de sorte que la communauté pourrait le faire).

Addendum Décembre 2018: Microsoft s'oriente vers .NET de Base et Linq-2-SQL n'est pas appuyer sur .NET de Base, de sorte que vous besoin de se déplacer à EF assurez-vous que vous pouvez passer en EF.De base à l'avenir.

Il y a aussi d'autres options à considérer, telles que LLBLGen.C'est une mature ORM solution qui existe déjà longtemps et qui a été prouvé plus d'avenir alors que le MS de solutions de données (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.de base).

LINQ to SQL et Entity Framework ressembler à la surface.Ils fournissent à la fois LINQ de l'interrogation d'une base de données à l'aide d'un modèle de données.

LINQ to SQL évolué à partir de l'LINQ projet, qui est sorti de l'équipe de travail avec le développement du langage.Alors que L'Entity Framework est un projet de l'équipe de Programmabilité de Données et a été concentrée sur l'Entité langage SQL.Microsoft a relly pas l'intention de depricate LINQ to SQL.

LINQ to SQL est encore la partie de ADO.NET alors que Entity framework a séparé de l'API.Entity framework est la version supérieure de LINQ to SQL.Entity framework utilise le Modèle de Données d'Entité pour créer des passerelles entre votre application et à votre magasin de données.C'est le Modèle de Données d'Entité, ou EDM, qui fournit la définition de votre schéma conceptuel ainsi que le schéma de base de données les informations nécessaires pour interagir avec la base de données et, enfin, un schéma de mappage que des liens vers deux.

Voici certaines des tâches effectuées par les Cadre de l'Entité(Entity data model).

• Génère automatiquement des classes à partir du modèle et des mises à jour de ces classes dynamiquement tout le temps les changements de modèle.

• Prend en charge l'ensemble de la connectivité de base de données afin que les développeurs ne sont pas accablés par avoir à écrire beaucoup de code pour interagir avec la base de données.

• Offre courante de la syntaxe de requête pour interroger le modèle, la base de données, et ensuite traduit ces requêtes dans des requêtes de la base de données peut comprendre.

• Fournit un mécanisme pour le suivi des modifications du modèle d'objets en tant qu'ils sont utilisé dans les applications et gère les mises à jour de la base de données.

Linq-to-SQL

Il est fournisseur prend en charge SQL Server uniquement.C'est une technologie de cartographie de la carte SQL Server tables de base de données .NET des objets.Microsoft, qui est la première tentative à un ORM - Object-Relational Mapper.

Linq-to-Entités

Est la même idée, mais en utilisant Entity Framework dans le fond, comme l'ORM de nouveau à partir de Microsoft, Il prend en charge plusieurs base de données principal avantage de l'entity framework est développeur peut travailler sur une base de données pas besoin d'apprendre la syntaxe d'effectuer toute opération sur les différentes bases de données différentes

Selon mon expérience personnelle Ef est mieux (si vous n'avez aucune idée sur SQL) performance dans LINQ est un peu plus rapide que de les comparer à EF raison LINQ langue écrite en lambda.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top