¿Cuáles son los malentendidos fundamentales que las personas tienen cuando comienzan a usar LINQ?¿Cuál es el error más grande que las personas cometen cuando comienzan a usar LINQ?
Por ejemplo, ¿piensan que es una cosa cuando realmente es otra cosa?
Y, ¿hay algunas mejores prácticas para emplear para evitar estos errores?
Que se debe utilizar para todo.
Sí, definitivamente pasé por esta fase.Sin embargo, me gusta pensar que he logrado vencer la tendencia ahora. :) ¡Es bueno para mi empleador que todo mi abuso de Linq haya tenido lugar en mi propio tiempo con proyectos personales! –
Sin duda es importante reconocer cuando no es el enfoque correcto. –
Veo muchos programadores que usan en exceso variables locales tipadas implícitamente. – RichardOD
Posiblemente, una de las ideas erróneas que las personas puedan tener es que la forma en que se escribe una consulta LINQ, especialmente LINQ2SQL, no tiene impacto en el rendimiento. Siempre se debe saber lo que sucede en el fondo, si uno tiene la intención de escribir código que tenga un alto rendimiento, de lo contrario podría terminar con tiempos de espera interesantes, OOMexceptions, desbordamiento de pila y tal ... =)
Esto es muy falso. Si bien es probable que LINQ2SQL no sufra de esto, LINQ a los objetos puede verse muy afectado por el orden de los elementos de consulta (por ejemplo, colocar una cláusula where ANTES de que una unión acelere considerablemente el código). –
He rastreado las consultas de linq2sql y he tenido resultados muy diferentes sobre cómo y en qué orden escribo las condiciones y los predicados. –
Adam: Parece que en realidad estás de acuerdo con la respuesta. Es un * concepto erróneo * de que no tiene ningún impacto en el rendimiento, en otras palabras, * puede * tener un efecto en el rendimiento. –
Aquí hay una, LINQ to SQL queries involving strings cause SQL Server procedure cache bloat Las personas deben tener en cuenta que
El error más grande que las personas cometen al usar LINQ es lo mismo que cuando las personas intentan utilizar cualquier tipo de tecnología que se encuentre sobre una tecnología que no tienen una buena conexión a tierra en.
Si no puede entender las consultas DB adecuadas/eficientes, se equivocará con LINQ.
Si no puede comprender los fundamentos básicos de ADO.NET y el acceso a los datos, es probable que se equivoque.
La gente piensa que al usar LINQ les permitirá pasar de largo, pero no lo hará.
Es cierto que las personas que ni siquiera tienen la idea de una transacción a menudo cometen los errores más estúpidos con LINQ (es decir, reutilizan una consulta porque no tienen la naturaleza perezosa de IQueryable, acaparando también el servidor de bases de datos ...) – em70
@ THETXI Su respuesta demuestra un error LINQ clásico al asumir Linq = Linq TO SQL. Consulte J. Skeets C# en profundidad para más información. – Ash
Al no entender la betweeen diferencias (o existencia de!):
.First()
.FirstOrDefault()
.Single()
.SingleOrDefault()
No entender deferred execution.
+1 para anotar Single. He estado usando Primero y comenté que "// Solo puede haber uno". –
Sí, la ejecución diferida me atrapó cuando comencé a usar LINQ por primera vez. Tuve una prueba de unidad que generaba diferentes datos de prueba cuando esperaba que fuera la misma. – RichardOD
Ese sitio web de ejecución diferida estaba atascado en un estado de carga media y pensé que era una broma inteligente hasta que volví a cargar la página web. –
Creo que entender el punto de la ejecución de la consulta suele ser un error (creer que está en el punto de la consulta y no en el momento en que se accede), junto con la creencia de que solo compila que es yendo a correr
Esto en referencia a Linq a SQL.
Una herramienta fantástica para Linq es LinqPad de Joe Albahari, me permitió aprender Linq mucho más rápido. Si no lo tienes, ¡consíguelo! Y ni siquiera estoy en la comisión;)
que sólo se refiere a LINQ to SQL
Totalmente de acuerdo. LINQ to XML y LINQ to objects son fantásticos. –
¡LINQ to XSD es incluso mejor! –
LINQ como lengua es bastante sencillo y no tan inesperado, especialmente si usted está familiarizado con la programación funcional.
El concepto de Deferred Execution es probablemente el más grande y una de las mejores características. Cuando utilizas LINQ que devuelve un IQueryable, es importante recordar que NO estás ejecutando el código que acabas de escribir. No es hasta que llame a uno de los métodos que produce algún otro resultado que la consulta se ejecuta.
Además, en términos del proveedor de LINQ to SQL, el mayor problema que he encontrado es el performance cost. Resulta que hay un costo de CPU significativo para la construcción de consultas SQL en las que se incurre cada vez que se ejecuta la consulta LINQ, a menos que precompile sus consultas de alto tráfico.
Algunas cosas, que vienen a la mente son
Ambos puntos son excelentes. Hace poco vi una docena de líneas de código precedidas por un comentario de que se hizo de esta manera para mejorar el rendimiento. Ejecuté un punto de referencia para mostrarle al autor que una declaración LINQ de una línea en realidad funcionaba más rápido que el bucle optimizado que tenía. – StriplingWarrior
Uno uno básica que veo en LINQ to SQL no comprende DataContext. Es un objeto de Unidad de trabajo y debe recrearse para cada unidad de trabajo.
Ejemplos/pruebas para los menos educados entre nosotros? –
@ AdamRobinson: está basado en ADO.NET, ve a leer la documentación de ADO.NET sobre la agrupación de conexiones y las mejores prácticas. –
Estoy totalmente de acuerdo con Adam Robinson, de hecho, el GRAN error es que la gente se detiene en la sintaxis de la belleza no profundizando en los hechos tecnológicos, en términos de impactos o vistas arquitectónicas.
A veces la gente piensa en ello como una cosa cuando en realidad es otra cosa ... sobre eso es importante señalar que Linq es una "Tecnología" y podría implementarse de muchas maneras, cada una de ellas podría afectar de manera diferente el rendimiento y diseño (por ejemplo), la sintaxis básica sigue siendo la misma pero las cosas subyacentes podrían cambiar.
En realidad, a partir de los grandes y crecientes implementaciones, no hay una lista completa de las mejores prácticas, las mejores prácticas podrían comenzar a partir de:
Usando linq2sql en las mesas sin claves principales (y sin definir una en el diseñador).
Especialmente si lo que están haciendo es una actualización, no actualiza nada y no obtiene ningún error.
Tenga en cuenta que estos elementos son específicos de LINQ to SQL –
Mucha gente piensa que LINQ es 'SQL mágico' que pueden usar en el Código. Parece SQL, pero es bastante diferente. Entender que es la diferencia y lo que es realmente haciendo evitará mucha frustración.
Hablando por mi cuenta, es importante saber cuándo una secuencia se almacenará en búfer o transmitirá.
Llenar un búfer con grandes cantidades de datos consumirá mucha memoria. Si es posible, se deben realizar operaciones como invertir, contar, ordenar, etc. una vez que los datos se hayan reducido. En une, la secuencia izquierda se transmite y la derecha se almacena en el búfer. Cuando hay una diferencia significativa en el tamaño, coloque el más pequeño a la derecha.
Entender de dónde se va de Linq2SQL/Entidades a Linq2Objects. Comprender qué es y qué no se está ejecutando en el motor de DB versus en su aplicación. Saber cuándo trabaja con objetos en memoria versus el proveedor de Linq subyacente que está utilizando, y luego saber cómo hacer la transición intencionalmente de Linq2SQL a Linq2Objects cada vez que necesite realizar un procesamiento posterior a la consulta aprovechando las funciones C#/.NET no admitidas en su proveedor.
¿Quiere decir LINQ -o-- LINQ to SQL? :-) –
Cualquiera o ambos :) –
Uso el :-) porque creo que es uno de los conceptos erróneos más grandes que la gente tiene sobre LINQ; que solo es LINQ to SQL. –