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).
También vea http://stackoverflow.com/questions/2438672/ –