.net - objects - linq>#

Pros y contras de LINQ(Language-Integrated Query)

Question

• ¿Cuáles son los pros y los contras de LINQ (Language-Integrated Query)?
• ¿Cuáles son los mejores y peores casos para usar LINQ?
• ¿Cómo se benefició o no se benefició el uso de LINQ?
• ¿Qué fuentes de datos benefician menos y más a LINQ?

Answer 1

Existe un problema con ellos de excepciones furtivas de bloques de captura de prueba por medio de una ejecución retrasada.

por ejemplo:

var l = new List<int>() {1, 2, 3};
try
{
    l.Select(x => x / 0);
}
catch
{
    // error
}

l.elementAt(0); // exception occurs here outside of the try catch

Lo cual puede ser complicado la primera vez que te topas, especialmente porque el depurador te indicará el código dentro del try-catch.

De lo contrario, los encuentro increíblemente útiles y ahorran mucho tiempo.

Answer 2

He usado LINQ principalmente para trabajar en la colección de objetos. LINQ funciona maravillosamente con colecciones de objetos, eliminando la necesidad de funciones de predicado en la mayoría de los casos.

Intenté usar LINQ to SQL hace un momento, pero me pareció que tenía poco poder y era torpe. En particular, no pude utilizar el diseñador de clases de SQL Database. Tal vez da intellisense en la base de datos, pero ¿quién lo necesita cuando tienes SQL?

Déjame decirte, sin embargo, es una buena idea aprender más acerca de LINQ, ya que las aplicaciones en el futuro solo deberían aumentar.

Answer 3

Mi parte favorita: usarlos para simplificar las pruebas de unidades de escritura. Además, las cadenas de IEnumerable me han instado a escribir interfaces más fluidas en mi código.

Contras: Lambdas y los métodos de extensión son mis martillos y todos los problemas son las uñas.

En general: insufló nueva vida a la programación en C # para mí.

Answer 4

Pro:

• LINQ to SQL permite RAD con base de datos muy bien
• Es fácil consultar múltiples fuentes de datos
• LINQ to SharePoint , LINQ to Active Directory , LINQ to TFS , LINQ to Umbraco , (y la lista continúa)

Estafa:

• Al igual que cualquier tecnología nueva, demasiadas personas no la entienden pero aún la usan

@Jon Skeet: otra gran respuesta, robas todos los truenos: P. Estoy totalmente de acuerdo con lo difícil que es escribir un proveedor, ¡estoy en proceso de hacerlo en este momento! ¿Estás familiarizado con Bart De Smet? Él tiene muchos buenos ejemplos de hacerlo.

Answer 5

Soy un gran admirador de LINQ, aunque debe mantenerse en perspectiva y no ser tratado como una bala de plata.

Pros:

• El enfoque declarativo hace que las consultas sean más fáciles de entender y más compactas
• Los árboles de extensibilidad y de expresión permiten la consulta más consistente de múltiples fuentes
• Incluso las consultas en proceso pueden implementarse de formas distintas a LINQ to Objects, por ejemplo, Parallel LINQ y mi propio marco de Push LINQ. Muy flexible.
• Fabulosamente útil para consultas en proceso, donde es más fácil de entender
• Genial para poder evitar SQL en cadenas, etc.
• Amplia gama de operadores proporcionados por defecto, y otros pueden agregarse fácilmente para LINQ a Objetos
• Las características de lenguaje introducidas principalmente para LINQ son ampliamente aplicables en otros lugares (yay para lambdas)

Contras:

• Las expresiones de consulta no se comprenden lo suficiente y se usan en exceso. A menudo, la invocación de método simple es más corta y más simple.
• Todavía existen incoherencias inevitables entre el imperativo de impedancia del proveedor, lo que es razonable pero debe entenderse
• Siempre habrá algunas cosas que puede hacer en SQL pero no en LINQ
• Sin entender lo que está pasando, es fácil escribir un código muy ineficiente
• Es difícil escribir un proveedor de LINQ. Esto bien puede ser inevitable, pero se apreciaría más orientación de Microsoft.
• Es una nueva forma de pensar acerca del acceso a los datos para la mayoría de los desarrolladores, y necesitará tiempo para comprenderlo.
• No específicamente LINQ pero relacionado con esto: la forma en que se descubren los métodos de extensión en C # no es lo suficientemente granular
• Algunos operadores "faltan", en particular los equivalentes de OrderBy para otras cosas además de ordenar, por ejemplo, encontrar el artículo con el valor máximo de una propiedad
• La ejecución diferida y la transmisión son poco conocidas (pero mejoran)
• La depuración puede ser muy difícil debido a la ejecución diferida y la transmisión
• En algunos casos específicos, LINQ puede ser significativamente más lento que el código manual. Cuanto mejor comprenda el funcionamiento interno, mejor podrá predecir esto. (Y, por supuesto, si el rendimiento es importante para usted, debe tener las pruebas adecuadas al respecto).

Creo que es mejor cuando se trata de consultas en proceso. Son fáciles de predecir, comprender y extender. Las tecnologías complementarias como LINQ to XML y Parallel LINQ son geniales. LINQ to Objects se puede usar casi en cualquier lugar.

LINQ to SQL, etc. son realmente agradables donde son apropiados, pero son más difíciles de entender y necesitan más experiencia. También son solo aplicables en ciertas áreas de tu código.