¿Para qué dominio de problema está hecho LINQ?

12

Cada vez que veo una pregunta publicada en Stack Overflow en C #, veo al menos una o dos respuestas publicadas que resuelven un problema con LINQ. Por lo general, las personas con muy buena reputación parecen usar LINQ como profesionales.

Entonces mi pregunta es, ¿para qué dominio de problema se debe usar LINQ?

También en las notas al margen: ¿Hay algún propósito en el que deba evitarse? ¿El tamaño del conjunto de datos afecta el rendimiento de las consultas LINQ?

usuario1816120
fuente
1
LINQ es para consultar gráficos de objetos. Es una consulta integrada en el idioma: le permite consultar y manipular colecciones.
Oded
1
probablemente es una pregunta que se puede cerrar, ya que puede haber una buena pregunta acechando sobre qué problemas linq encaja bien
jk.
1
Linq es declarativo. Usted declara "qué" quiere sin especificar "cómo" se hace. Para linq eso significa que puede usar consultas para indicar lo que desea. El código declarativo puede ser más corto y más fácil de entender para algunos problemas.
mike30

Respuestas:

16

LINQ está diseñado principalmente para permitir consultas funcionales puras y transformaciones en secuencias de datos (notará que todas las extensiones LINQ aceptan delegados Func pero no delegados Action). En consecuencia, el caso más común de un bucle que no encaja muy bien con LINQ es uno que se trata de efectos secundarios funcionales no puros, p. Ej.

foreach(var x in list) Console.WriteLine(x);

Para mejorar en el uso de LINQ, solo practique usarlo.

Cada vez que usted está a punto de escribir foro de foreachbucle para hacer algo con una colección, parada, considere si es un buen ajuste para LINQ (es decir, no se trata sólo de realizar un efecto de acción / lateral sobre los elementos), y si es así se obligue a escribir usando LINQ.

También puede escribir la foreachversión primero y luego volver a escribirla en una versión LINQ.

Como señala svick, LINQ debería ser para hacer que su programa sea más legible. Por lo general, es bueno en esto, ya que tiende a enfatizar la intención del código en lugar del mecanismo; sin embargo, si descubre que no puede hacer que sus consultas sean más legibles que un bucle simple, no dude en seguir el bucle.

Si necesita ejercicios para practicar, la mayoría de los ejercicios de programación funcional se correlacionarán muy bien con LINQ, por ejemplo, 99 problemas (especialmente los primeros 20 más o menos) o el proyecto Euler .

jk.
fuente
Puede que tenga que eliminar esta pregunta ahora. El moderador comentó que no es apto para la comunidad. Si siente lo contrario, dígamelo.
user1816120
1
Agregaría que si lo reescribe en LINQ y el original es aún más legible, conserve el original y elimine la versión de LINQ. A veces, LINQ simplemente no agrega nada.
svick
@svick en teoría sí, no estoy seguro de poder pensar en ningún ejemplo de esto;)
jk.
1
@jk. Por ejemplo, ReSharper a veces ofrece convertir mi bucle a LINQ usando Aggregate(). Creo que la mayoría de las veces, el bucle es más legible.
svick
@svick probablemente sea un problema de lo que estás acostumbrado, aunque admitiré que agregado es un nombre torpe para fold
jk.
1

Para responder la pregunta editada: en resumen, es beneficioso usar LINQ siempre que tenga que implementar la funcionalidad de "consulta" (eso es lo que significa la Q en LINQ). Definir un dominio exacto es difícil, pero simplifica enormemente una variedad de tareas asociadas con la extracción y manipulación de datos de colecciones.

Para explicar un poco, se ha incorporado una gran cantidad de funcionalidades de consulta directamente al lenguaje (o más bien, a los diversos implementadores de LINQ), por lo que se manejan cosas como agregaciones, ordenación, agrupación, filtrado, proyecciones, uniones (y muchas más). tú. Las soluciones basadas en LINQ también suelen ser mucho más cortas que si las implementara "a mano", y también comunican su intención mucho mejor.

Un ejemplo simple que a menudo ayuda a transmitir el poder de LINQ es mostrar los contenidos de un directorio, agrupados por extensión. Ejecute una implementación imperativa típica en su cabeza: habrá muchos detalles de implementación ya desde el principio. Quizás usaremos a Dictionary<String, List<String>>para indexar los archivos por extensión. Por supuesto, tendremos que verificar si ya existe una clave, instanciar una lista, agregarla, etc. Podría ser algo como:

Dictionary<string, List<string>> fileGroups = new Dictionary<string, List<string>>();

foreach (string file in Directory.GetFiles(Environment.CurrentDirectory))
{
    string extension = Path.GetExtension(file).ToLower();

    if (!fileGroups.ContainsKey(extension))
    {
        fileGroups[extension] = new List<string>();
    }

    fileGroups[extension].Add(file);
}

Considere el equivalente de LINQ:

var query = from file in Directory.GetFiles(Environment.CurrentDirectory)
            group file by Path.GetExtension(file).ToLower();

Tenga en cuenta que la consulta en sí es de solo 2 líneas, ciertamente más corta que cualquier solución imperativa que podríamos haber ideado. También es bastante legible; La relación señal-ruido es más alta que con la primera solución. Para aquellos que son nuevos en LINQ, generará los resultados de esa consulta de la siguiente manera:

foreach (var fileGroup in query)
{
    Console.WriteLine(String.Format("*** Files with extension: {0}", group.Key));

    foreach (string file in fileGroup)
    {
        Console.WriteLine(file);
    }
}

Con ejemplos más complejos, las diferencias normalmente se vuelven aún más vastas (considere simplemente agrupar por múltiples campos, por ejemplo). Entonces, para resumir, LINQ resuelve muchos problemas de consulta de datos "día a día" de una manera que a menudo es más corta y más descriptiva. Esto tiene un costo leve de tener que aprender la sintaxis y la tecnología, pero los beneficios superan en gran medida a los negativos.

Daniel B
fuente
¿Clasifica el mapa o lo pliega como "consultas"? Realmente no, pero supongo que podría verlo tal vez ... Normalmente pensaría en un agregado como resultado de un cálculo, no una "consulta"
Jimmy Hoffa
@JimmyHoffa Me refiero principalmente a la aplicación del cálculo a la colección subyacente, no necesariamente al cálculo en sí. Pero probablemente haya agujeros en mi analogía, está destinado a ser ilustrativo en lugar de 100% correcto.
Daniel B
@JimmyHoffa no, pero no estoy seguro de si hay una definición estricta de qué es una consulta para comenzar
jk.
0

Se han desarrollado diferentes lenguajes a lo largo del tiempo para los diversos tipos de fuentes de datos, por ejemplo, SQL para bases de datos relacionales y XQuery para XML. Por lo tanto, los desarrolladores han tenido que aprender un nuevo lenguaje de consulta para cada tipo de fuente de datos o formato de datos que deben admitir. LINQ simplifica esta situación al ofrecer un modelo consistente para trabajar con datos en varios tipos de fuentes y formatos de datos. En una consulta LINQ, siempre está trabajando con objetos. Para más información visite http://msdn.microsoft.com/en-us/library/bb397906.aspx

Rabbil
fuente
Exactamente LINQ es una API de abstracción para trabajar con colecciones. Algunos beneficios importantes: ¡usando C # obtienes estática! Verificación de sus consultas y transformaciones
AndreasScheinert