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

91

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.

Marcel
fuente
2
También vea stackoverflow.com/questions/2438672
Henk Holterman

Respuestas:

110
  • 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

marc_s
fuente
1
Felicitaciones por 50k, ahora ha pasado oficialmente demasiado tiempo en StackOverflow. ;)
Aaronaught
1
@Aaronaught: gracias, ¡y tienes toda la razón! :-) Tengo que dejar una adicción a cada hombre, ¿no? ¡¿¡¿¡¿Por favor?!?!?!
marc_s
1
marc_s, gracias por esta respuesta. ¿Puedes contarnos algo sobre el rendimiento? Por su respuesta, supongo que Linq-to-Entities es el más avanzado y, por lo tanto, probablemente el más eficaz.
Marcel
2
@Marcel: desde mi instinto (sin hechos concretos), diría: Linq-to-SQL o es el más rápido (solo una capa entre la base de datos y el modelo de objetos), Linq-to-Dataset un segundo cercano y Linq-to -Entities es el último, porque Entity Framework siempre tiene dos capas de mapeo (por lo tanto, la mayor complejidad). Pero de nuevo: solo un presentimiento, sin números que respalden eso
marc_s
3
@marc_s Sé que esta es una publicación antigua, pero LINQ to Entities probablemente sería más rápido que LINQ to Dataset en la mayoría de los casos. LINQ to Dataset no es realmente un tipo, es LINQ sobre objetos de los que está utilizando el conjunto de datos como objeto. Dado que LINQ over objects no realiza ningún SQL, primero debe crear su conjunto de datos a partir de la fuente SQL, y LINQ over objects no puede ayudarlo a realizar optimizaciones de consulta al recuperar los datos en el conjunto de datos. Eso y los conjuntos de datos tienen un rendimiento terrible, ya que todas las columnas están encuadradas y todo ese tipo de cambio mata el rendimiento.
Robert McKee
38

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

Marc Gravell
fuente
Marc, gracias por esta información. Sin embargo, no pregunté sobre aspectos internos tan detallados. -1, lo siento, porque no responde la pregunta.
Marcel
7
Como alguien que escribe su propio proveedor LINQ, esta es la mejor respuesta que he visto hasta ahora. No estoy de acuerdo con el -1.
Dan Barowy
30

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.

Simon P Stevens
fuente
3
en realidad, Linq-to-SQL es solo SQL Server , no solo "cualquier" backend de base de datos SQL.
marc_s
3
@marc_s: Buen lugar. Gracias. Aunque, si alguien está interesado, hay proveedores externos de Linq to sql para otras bases de datos si los desea. Consulte code2code.net/DB_Linq , o Google para otros. Sin embargo, no puedo comentar sobre su calidad.
Simon P Stevens
1
Simon, gracias especialmente por ese útil resumen de 2 líneas del marco de la Entidad. +1
Marcel