linq linq-to-sql stored-procedures ado.net

¿Cuáles son las ventajas de LINQ to SQL?



linq-to-sql stored-procedures (5)

Cambiamos a LINQ2Entity en el entorno de Entity Framework recientemente. Antes, teníamos SQLadapters básicos. Dado que la base de datos con la que estamos trabajando es bastante pequeña, no puedo comentar sobre el rendimiento de LINQ.

Debo admitir, sin embargo, que las consultas de escritura se han vuelto mucho más fáciles, y la adición de Entidades, sí permite un tipeo fuerte.

Acabo de empezar a utilizar LINQ to SQL en un proyecto de tamaño mediano, y me gustaría aumentar mi comprensión de las ventajas que ofrece L2S.

Una desventaja que veo es que agrega otra capa de código, y tengo entendido que tiene un rendimiento más lento que el uso de procedimientos almacenados y ADO.Net. También parece que la depuración podría ser un desafío, especialmente para consultas más complejas, y que éstas podrían terminar siendo trasladadas a un proceso almacenado de todos modos.

Siempre he querido una forma de escribir consultas en un mejor entorno de desarrollo. ¿Las consultas L2S son la solución que estaba buscando? ¿O acabamos de crear otra capa sobre SQL, y ahora tenemos el doble de qué preocuparnos?

Debo decir que son lo que has estado buscando. Lleva algo de tiempo acostumbrarse, pero una vez que lo haces, no puedes pensar en volver atrás (al menos para mí). En cuanto a los procedimientos linq y almacenados, puede tener un rendimiento bajo en cualquiera de los casos si lo compila mal. Me mudé a linq para SQL algunos procedimientos almacenados de un cliente que estaban muy codificados, por lo que el tiempo se redujo de 20 segundos (totalmente inaceptable para una aplicación web) a <1 seg. Y mucho menos código que la solución de procedimiento almacenado.

Actualización 1: también obtienes mucha flexibilidad, ya que puedes limitar las columnas de lo que obtienes y en realidad solo lo recuperarás. En la solución de procedimiento almacenado, debe definir un procedimiento para cada conjunto de columnas que está recibiendo, incluso si las consultas subyacentes son las mismas.

Solo unos pocos pensamientos rápidos.

LINQ en general

  • Consultar colecciones en memoria y almacenes de datos fuera de proceso con la misma sintaxis y operadores
  • Un estilo declarativo funciona muy bien para las consultas: en muchos casos es más fácil leer y escribir
  • La integración ordenada del lenguaje permite escribir nuevos proveedores (tanto dentro como fuera del proceso) y aprovechar la misma sintaxis de expresión de consulta

LINQ to SQL (u otra base de datos LINQ)

  • Escribir consultas donde las necesita en lugar de hacerlo como procesos almacenados hace que el desarrollo sea mucho más rápido: hay muchos menos pasos involucrados solo para obtener los datos que desea
  • Muchas menos cadenas (procs almacenados, nombres de parámetros o simplemente SQL) involucrado donde los errores tipográficos pueden ser irritantes; el otro lado de esta moneda es que obtienes Intellisense para tu consulta
  • A menos que trabaje con los datos "en bruto" de ADO.NET, tendrá un modelo de objetos en alguna parte. ¿Por qué no dejas que LINQ to SQL lo haga por ti? Me gusta simplemente poder hacer una consulta y recuperar los objetos, listos para usar.
  • Esperaría que el rendimiento sea bueno, y donde no lo esté, puede sintonizarlo usted mismo o recurrir al SQL directo. El uso de un ORM ciertamente no elimina la necesidad de crear los índices correctos, etc., y normalmente debería verificar el SQL generado para consultas no triviales.

No es una panacea de ninguna manera, pero lo prefiero a hacer consultas SQL directamente o usar procesos almacenados.

Ventajas L2S ofrece:

  • Sin cadenas mágicas, como las que tienes en las consultas SQL
  • Intellisense
  • Comprobación de compilación cuando cambia la base de datos
  • Un desarrollo más rápido
  • Patrón de unidad de trabajo (contexto)
  • Objetos de dominio generados automáticamente que son proyectos pequeños utilizables
  • Carga lenta.
  • Aprender a escribir linq queries / lambdas es algo que debe aprenderse para los desarrolladores de .NET.

En cuanto al rendimiento:

  • Lo más probable es que el rendimiento no sea un problema en la mayoría de las soluciones. Preoptimizar es un antipatrón. Si luego ve que algunas áreas de la aplicación se ralentizan, puede analizar estas partes y, en algunos casos, incluso intercambiar algunas consultas de linq con procedimientos almacenados o ADO.NET.
  • En muchos casos, la función de carga diferida puede acelerar el rendimiento, o al menos simplificar mucho el código.

En cuanto a la depuración:

  • En mi opinión, la depuración de Linq2Sql es mucho más fácil que los procedimientos almacenados y ADO.NET. Recomiendo que eche un vistazo a Linq2Sql Debug Visualizer , que le permite ver la consulta, e incluso activar una ejecución para ver el resultado al depurar.
  • También puede configurar el contexto para escribir todas las consultas SQL en la ventana de la consola, más información aquí

En cuanto a otra capa:

  • Linq2Sql se puede ver como otra capa, pero es una capa puramente de acceso a datos. Los procedimientos almacenados también son otra capa de código, y he visto muchos casos en los que parte de la lógica empresarial se ha implementado en procedimientos almacenados. En mi opinión, esto es mucho peor porque, a continuación, divide la capa empresarial en dos lugares, y será más difícil para los desarrolladores obtener una visión clara del dominio comercial.