2010-03-14 39 views
73

He estado trabajando durante bastante tiempo con LINQ. Sin embargo, sigue siendo un poco misterioso cuáles son las diferencias reales entre los sabores mencionados de LINQ.Cuál es la diferencia entre "LINQ to Entities", "LINQ to SQL" y "LINQ to Dataset"

La respuesta correcta contendrá una pequeña 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 ...

P.S. Sé que hay muchas fuentes de información, pero estoy buscando una especie de "hoja de referencia" que instruya a un novato dónde dirigirse para un objetivo específico.

+2

También vea http://stackoverflow.com/questions/2438672/ –

Respuesta

93
  • todos ellos son LINQ - Language Integrated Query - por lo que todos comparten muchas cosas en común. Todos estos "dialectos" básicamente le permiten hacer una selección de datos de estilo de consulta, de varias fuentes.

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

  • LINQ-a-Entidades es la misma idea, pero utilizando Entity Framework en el fondo, ya que el ORM - de nuevo de Microsoft, pero el apoyo a múltiples backends de bases de datos

  • LINQ-a-bases de datos es LINQ, pero usar está en contra de los DataSets ADO.NET 2.0 de "estilo antiguo" - en los tiempos previos a los ORM de Microsoft, todo lo que podía hacer con ADO.NET era devolver DataSets, DataTables, etc., y consultas de Linq-to-DataSets esos almacenes de datos para datos. Así pues, en este caso, que le devuelve un DataTable o conjuntos de datos (System.Data espacio de nombres) a partir de un motor de base de datos y consulta los que utilizan la sintaxis de LINQ

+0

Enhorabuena 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?!?!?! –

+0

marc_s, gracias por esta respuesta. ¿Puedes decir algo sobre el rendimiento? De su respuesta, ¿supongo que Linq-to-Entities está más avanzado y, por lo tanto, probablemente tenga más rendimiento? – Marcel

24

LINQ significa Language Integrated Query. Le permite usar el lenguaje de consulta "estilo SQL" directamente dentro de C# para extraer información de las fuentes de datos.

  • esa fuente de datos podría ser una base de datos del servidor SQL - esto es LINQ a SQL
  • Esa fuente de datos podría ser un contexto de datos de objetos de entidad marco - LINQ a las entidades.
  • Esa fuente de datos podría ser conjuntos de datos 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 consultas, el resto del nombre describe la fuente de los datos que se están consultando.

Por un poco de fondo extra:

Los conjuntos de datos son objetos de ADO.NET donde los datos se cargan desde una base de datos en una.net Dataset y Linq se pueden usar para consultar esos datos después de que se carguen.

Con LINQ a SQL definir clases .NET que se asignan a la base de datos y LINQ to SQL se encarga de cargar los datos de la base de datos del servidor SQL

Y por último el marco Entidad es una sistema donde puede definir una asignación de base de datos y objetos en XML, y luego puede usar Linq para consultar los datos que se cargan a través de esta asignación.

+3

en realidad, Linq-to-SQL es ** SQL Server ** solamente, no solo "cualquier" base de datos SQL. –

+3

@marc_s: Buen lugar. Gracias. Aunque, si alguien está interesado, hay proveedores Linq a terceros para otras bases de datos si lo desea. Ver http://code2code.net/DB_Linq/, o Google para otros. Sin embargo, no puedo comentar sobre su calidad. –

+1

Simon, gracias especialmente por el útil resumen de 2 líneas del marco Entitiy. +1 – Marcel

36

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

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

la que está asignado por el compilador a código:

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

y aquí comienza la magia real. Tenga en cuenta que no hemos dicho qué Foo está aquí, ¡y al compilador no le importa! Siempre y cuando se puede resolver algún método adecuado llamado Where que puede tomar una lambda, y el resultado de eso tiene un poco de métodoSelect que puede aceptar la lambda, es feliz.

Ahora consideran 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 a una expresión de árboles (un modelo de tiempo de ejecución que representa la lambda en un modelo de objeto).

Para datos en memoria (normalmente IEnumerable<T>), simplemente ejecuta el delegado - fino y rápido. Pero para IQueryable<T> la representación de objeto de la expresión (a LambdaExpression<...>) puede separarla y aplicarla a cualquier ejemplo de "LINQ-a-algo".

Para bases de datos (LINQ a SQL, LINQ a Entidades) 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) significa escribiendo una consulta HTTP.

Ejecutar una consulta TSQL bien escrita que devuelve una pequeña cantidad de datos es más rápida que cargar una base de datos completa a través de la red y luego filtrar en el cliente. Sin embargo, ambos tienen escenarios ideales y escenarios erróneos.

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

+0

Marc, gracias por esta idea. Sin embargo, no pregunté acerca de tales detalles internos. -1, lo siento, porque no responde la pregunta. – Marcel

+6

Como alguien que escribe su propio proveedor de LINQ, esta es la mejor respuesta que he visto hasta ahora. No estoy de acuerdo con el -1. –