¿Cuál es la diferencia entre "LINQ to Entities", "LINQ to SQL" y "LINQ to Dataset"?

He estado trabajando durante bastante tiempo con LINQ. Sin embargo, sigue siendo un misterio cuáles son las diferencias reales entre los sabores mencionados de LINQ.

La respuesta exitosa contendrá una breve diferenciación entre ellos. ¿Cuál es el objetivo principal de cada sabor, cuál es el beneficio y hay un impacto en el rendimiento ...

PD: Sé que hay muchas fuentes de información, pero estoy buscando una especie de "hoja de trucos" que indique al novato dónde dirigirse hacia un objetivo específico.

• todos son LINQ (Language Integrated Query), por lo que todos comparten muchos puntos en común. Todos estos "dialectos" básicamente le permiten hacer una selección de datos al estilo de una consulta, de varias fuentes.

• Linq-to-SQL es el primer intento de Microsoft en un ORM - Object-Relational Mapper. Solo es compatible con SQL Server. Es una tecnología de mapeo para mapear tablas de bases de datos de SQL Server a objetos .NET.

• Linq-to-Entities es la misma idea, pero usando Entity Framework en segundo plano, como ORM, nuevamente de Microsoft, pero compatible con múltiples backends de bases de datos

• Linq-to-DataSets es LINQ, pero el uso está en contra de los conjuntos de datos ADO.NET 2.0 "de estilo antiguo": en los tiempos anteriores a los ORM de Microsoft, todo lo que podía hacer con ADO.NET era devolver conjuntos de datos, tablas de datos, etc., y Linq -to-DataSets consulta esos almacenes de datos para obtener datos. Entonces, en este caso, devolvería un DataTable o DataSets (espacio de nombres System.Data) desde un backend de base de datos, y luego consultaría los que usan la sintaxis LINQ

LINQ es un amplio conjunto de tecnologías, basadas en (por ejemplo) una sintaxis de comprensión de consultas, por ejemplo:

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

que es mapeado por el compilador en código:

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

y aquí comienza la verdadera magia. Tenga en cuenta que no hemos dicho lo que Foohay aquí, ¡y al compilador no le importa! Siempre que pueda resolver algún método adecuado llamado Whereque pueda tomar una lambda, y el resultado de eso tenga algún Select método que pueda aceptar la lambda, es feliz.

Ahora considera que el lambda puede ser compilado , ya sea en un método anónimo (delegado, para LINQ a objetos, que incluye LINQ a conjunto de datos), o de una expresión de árboles (un modelo de tiempo de ejecución que representa la lambda en un modelo de objetos ).

Para los datos en memoria (típicamente IEnumerable<T>), simplemente ejecuta el delegado, de manera precisa y rápida. Pero para IQueryable<T>la representación de objeto de la expresión (a LambdaExpression<...>) puede separarla y aplicarla a cualquier ejemplo de "LINQ-to-Something".

Para bases de datos (LINQ-to-SQL, LINQ-to-Entities), esto podría significar escribir TSQL, por ejemplo:

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

Pero podría (para ADO.NET Data Services, por ejemplo) significar escribir una consulta HTTP.

Ejecutar una consulta TSQL bien redactada que devuelve una pequeña cantidad de datos es más rápido que cargar una base de datos completa en la red y luego filtrar en el cliente. Sin embargo, ambos tienen escenarios ideales y escenarios completamente equivocados.

El objetivo y el beneficio aquí es permitirle usar una sintaxis única, comprobada estática para consultar una amplia gama de fuentes de datos y hacer que el código sea más expresivo (el código "tradicional" para agrupar datos, por ejemplo, no lo es muy claro en términos de lo que está tratando de hacer: se pierde en la masa de código).

LINQ es sinónimo de consulta integrada de lenguaje. Le permite utilizar un lenguaje de consulta de "estilo SQL" directamente dentro de C # para extraer información de fuentes de datos.

• Esa fuente de datos podría ser una base de datos de servidor SQL: esto es Linq to SQL
• Esa fuente de datos podría ser un contexto de datos de objetos de marco de entidad: Linq a entidades .
• Esa fuente de datos podría ser conjuntos de datos de ADO.net: Linq a Dataset .

Esa fuente de datos también podría ser un archivo XML: Linq a XML .
O incluso solo una clase Collection de objetos simples: Linq to Objects .

LINQ describe la tecnología de consulta, el resto del nombre describe la fuente de los datos que se consultan.

Para un poco de información adicional:

Los conjuntos de datos son objetos de ADO.net donde los datos se cargan desde una base de datos en un conjunto de datos .net y Linq se puede usar para consultar esos datos después de que se cargan.

Con Linq to SQL usted define clases .net que se asignan a la base de datos y Linq-to-SQL se encarga de cargar los datos desde la base de datos del servidor SQL.

Y finalmente, Entity framework es un sistema donde puede definir una base de datos y un mapeo de objetos en XML, y luego puede usar Linq para consultar los datos que se cargan a través de este mapeo.