Quelle est la différence entre «LINQ to Entities», «LINQ to SQL» et «LINQ to Dataset»

Je travaille depuis un certain temps maintenant avec LINQ. Cependant, les véritables différences entre les saveurs mentionnées de LINQ restent un peu mystérieuses.

La réponse réussie contiendra une brève différenciation entre eux. Quel est l'objectif principal de chaque saveur, quel est l'avantage et y a-t-il un impact sur les performances ...

PS Je sais qu'il existe de nombreuses sources d'informations, mais je recherche une sorte de "feuille de triche" qui indique à un débutant où se diriger vers un objectif spécifique.

• tous sont LINQ - Language Integrated Query - ils partagent donc tous beaucoup de points communs. Tous ces "dialectes" vous permettent essentiellement de faire une sélection de données de type requête, à partir de diverses sources.

• Linq-to-SQL est la première tentative de Microsoft sur un ORM - Object-Relational Mapper. Il prend uniquement en charge SQL Server. Il s'agit d'une technologie de mappage pour mapper les tables de base de données SQL Server sur des objets .NET.

• Linq-to-Entities est la même idée, mais en utilisant Entity Framework en arrière-plan, comme ORM - encore une fois de Microsoft, mais prenant en charge plusieurs backends de base de données

• Linq-to-DataSets est LINQ, mais l'utilisation est contre les DataSets ADO.NET 2.0 «à l'ancienne» - à l'époque précédant les ORM de Microsoft, tout ce que vous pouviez faire avec ADO.NET était de renvoyer des DataSets, des DataTables, etc., et Linq -to-DataSets interroge ces magasins de données pour les données. Donc, dans ce cas, vous retournez un DataTable ou DataSets (espace de noms System.Data) à partir d'un backend de base de données, puis interrogez ceux à l'aide de la syntaxe LINQ

LINQ est un large ensemble de technologies, basé sur (par exemple) une syntaxe de compréhension de requête, par exemple:

var qry = from x in source.Foo
          where x.SomeProp == "abc"
          select x.Bar;

qui est mappé par le compilateur en code:

var qry = source.Foo.Where(x => x.SomeProp == "abc").Select(x => x.Bar);

et ici la vraie magie commence. Notez que nous n'avons pas dit ce qu'il Fooy a ici - et le compilateur s'en fiche! Tant qu'il peut résoudre une méthode appropriée appelée Wherequi peut prendre un lambda, et que le résultat de cela a une Select méthode qui peut accepter le lambda, il est heureux.

Considérez maintenant que le lambda peut être compilé soit dans une méthode anonyme (délégué, pour LINQ-to-Objects, qui inclut LINQ-to-DataSet), soit dans un expression-tree (un modèle d'exécution qui représente le lambda dans un modèle objet ).

Pour les données en mémoire (généralement IEnumerable<T>), il exécute simplement le délégué - très bien et rapidement. Mais pour IQueryable<T>la représentation objet de l'expression (a LambdaExpression<...>), elle peut la séparer et l'appliquer à n'importe quel exemple "LINQ-to-Something".

Pour les bases de données (LINQ-to-SQL, LINQ-to-Entities), cela peut signifier écrire TSQL, par exemple:

SELECT x.Bar
FROM [SomeTable] x
WHERE x.SomeProp = @p1

Mais cela pourrait (pour ADO.NET Data Services, par exemple) signifier écrire une requête HTTP.

L'exécution d'une requête TSQL bien écrite qui renvoie une petite quantité de données est plus rapide que le chargement d'une base de données entière sur le réseau, puis le filtrage au niveau du client. Les deux ont des scénarios idéaux et des scénarios tout à fait faux, cependant.

L'objectif et l'avantage ici est de vous permettre d'utiliser une seule syntaxe vérifiée de manière statique pour interroger un large éventail de sources de données, et de rendre le code plus expressif (le code "traditionnel" pour regrouper des données, par exemple, n'est pas très clair en termes de ce qu'il essaie de faire - il est perdu dans la masse du code).

LINQ signifie requête intégrée au langage. Il vous permet d'utiliser le langage de requête de «style SQL» directement dans C # pour extraire des informations à partir de sources de données.

• Cette source de données pourrait être une base de données de serveur SQL - c'est Linq to SQL
• Cette source de données pourrait être un contexte de données d'objets de structure d'entité - Linq aux entités .
• Cette source de données peut être des ensembles de données ADO.net - Linq vers Dataset .

Cette source de données peut également être un fichier XML - Linq to XML .
Ou même juste une classe Collection d'objets simples - Linq to Objects .

LINQ décrit la technologie d'interrogation, le reste du nom décrit la source des données interrogées.

Pour un peu plus de fond:

Les ensembles de données sont des objets ADO.net dans lesquels les données sont chargées à partir d'une base de données dans un ensemble de données .net et Linq peut être utilisé pour interroger ces données après leur chargement.

Avec Linq to SQL, vous définissez des classes .net qui correspondent à la base de données et Linq-to-SQL se charge du chargement des données depuis la base de données du serveur SQL

Enfin, le framework Entity est un système dans lequel vous pouvez définir une base de données et un mappage d'objets en XML, puis utiliser Linq pour interroger les données chargées via ce mappage.