Aquí podría ser tu PUBLICIDAD


¿LinqToSQL es lo suficientemente potente? ¿No es una interfaz más poderosa pero igualmente fluida, fácil de construir?

votos
0

En una pregunta anterior, pregunté si las bibliotecas ORM no eran óptimas y recibí muchos comentarios excelentes. A medida que he pensado más sobre el tema, he llegado a la conclusión de que el beneficio principal de LinqToSQL (ahora) y la promesa de LinqToEntities (en el futuro) radica en su capacidad para reducir la falta de coincidencia entre código de procedimiento y SQL. Dadas las limitaciones de LinqToSQL como un lenguaje completo de consulta de datos, no estoy dispuesto a aceptar que sus ventajas vayan más allá de esto, pero me gustaría conocer la opinión de los demás.

Para empezar, ¿qué quiero decir con una falta de coincidencia entre el código de procedimiento y SQL? Si alguna vez ha desarrollado una aplicación de base de datos, probablemente se haya familiarizado (y esté cansado) con los pasos necesarios para interactuar con una base de datos: configure todos los parámetros, ingrese el comando SQL y luego convierta los resultados esperados a variables o instancias usadas en el código.

LinqToSql hace esto mucho más fácil mediante el uso de interfaces fluidas, expresiones lambda, métodos de extensión, etc. El resultado final es que es fácil insertar tipos escalares C # nativos en la llamada de recuperación de datos y generar automáticamente clases C # nativas . Tome este ejemplo del sitio web de MS:

var q =
   from c in db.Customers
   where c.City == London
   select c;
foreach (var cust in q)
   Console.WriteLine(id = {0}, City = {1},cust.CustomerID, cust.City);

¡Muy genial!

Entonces, ¿cuál es el problema?

Bueno, como señalé en el artículo vinculado a en la parte superior, hay una serie de problemas. El mayor inconveniente para mí fue que cualquiera que sea mínimamente competente en SQL golpeará de inmediato los obstáculos. No es solo que muchos de los constructos creados como alternativas al SQL sean desconocidos o incluso torpes (¿Agrupar? Estamos hablando de lo feo en LinqToSql). El problema más grande es que hay una serie de construcciones comunes que simplemente no son compatibles de forma nativa (por ejemplo, DateDiff). En el mejor de los casos, puede escapar de Linq y enviar código SQL al flujo de llamadas de Linq.

Entonces, ¿no es mejor simplemente insertar SQL en C # (o VB) de manera que le permita establecer libremente su SQL, pero que también le brinde fácil incrustación de parámetros y conversión automática a clases nativas? Por ejemplo, si implementamos solo seis funciones en una sola clase, podemos escribir algo como esto (donde qry es una instancia de nuestra clase de consulta):

var ListOfEnrollees = 
           qry.Command(Select b.FirstName, b.LastName, b.ID From ClassEnroll a inner join Folder b on (a.ClientID = b.ClientID) )
             .Where (a.ClassID, classID)
             .AND()
             .Append((DateDiff(d, a.ClassDate, @ClassDate) = 0) Order By LastName;)
             .ParamVal(classDate)
             .ReturnList<EnrollListMemberData>();

El comando simplemente nos inicia recogiendo la instrucción SQL, dónde inicia nuestra cláusula SQL Where e ingresa el primer parámetro, agrega tachuelas en más SQL, ParamVal simplemente ingresa un valor de parámetro para coincidir con el parámetro SQL encontrado en la línea anterior, y ReturnList lo hace la magia necesaria para convertir a una clase. Tenga en cuenta que esto es solo SQL: las uniones son triviales, DateDiff (o cualquier otra construcción SQL) es compatible, etc. Podemos probarlo en una ventana SQL y luego simplemente cortar y pegar en nuestro código, dividiéndolo según corresponda para ingresar nuestros parámetros No podría ser más fácil.

Ahora, el constructo básico que se muestra arriba me parece escandalosamente simple y puede manejar CUALQUIER construcción SQL usando el conocimiento de SQL que ya tengo. Tuve que usar algunas reflexiones y algunas de las otras nuevas construcciones C # 3 para hacer que las llamadas ReturnList (y similares) funcionasen, pero, en general, fue bastante sencillo. También agregué varias campanas y silbatos para hacer que la interfaz sea más fluida. Entonces, aquí está mi pregunta y donde me gustaría escuchar los comentarios de la comunidad:

¿Por qué tendría que dominar las complejidades de LinqToEntities o incluso incurrir en la sobrecarga de LinqToSql? ¿Esto no me da todo lo que LinqToSql me da y más? ¿No cubre incluso LinqToEntities a excepción de exóticas asignaciones relacionales a objetos?

Actualización : Hamish Smith argumenta a continuación que LINQ puede algún día ser un lenguaje de manipulación de datos totalmente capaz tan poderoso que SQL ni siquiera es necesario. Este es un argumento importante que no discutí pero con el que estoy de acuerdo. La esencia de mi posición es que, si bien hay algunas ventajas prácticas para LinqToSql, aún queda muy por debajo de la meta de Hamish. Este es un inconveniente muy real y significativo.

Hamish también argumenta, correctamente, que todavía estoy trabajando con SQL incorporado; no he resuelto el problema. Para mí, sin embargo, esta es una característica y no un error. SQL aún es mucho mejor para seleccionar y manipular datos relacionales (que es, después de todo, con lo que estamos trabajando) que quiero poder usarlo para crear mi solución. Estoy argumentando que SQL incrustado no es el problema tanto como la impedancia no coinciden entre él y C #. Sin embargo, al utilizar las nuevas características inspiradas en Linq de C # 3, puedo eliminar en gran medida este desequilibrio de impedancia y obtener lo mejor de ambos mundos.

Publicado el 12/03/2009 a las 19:57
fuente por usuario Mark Brittingham
En otros idiomas...        العربية       

6 respuestas

votos
2

Entonces, ¿no es mejor simplemente insertar SQL en C # (o VB) de manera que le permita establecer libremente su SQL, pero que también le brinde fácil incrustación de parámetros y conversión automática a clases nativas?

Lo que suelo hacer se acerca mucho a esto. Escribo el SQL en un procedimiento almacenado, por lo que tengo la libertad de SQL real. En C # utilizo el DBML de Linq para acceder a los procedimientos almacenados de forma natural. Esto se siente como lo mejor de ambos mundos.

La solución real parece aún más simple para mí: incrustar SQL en código C # y hacer que el compilador genere las clases fuertes. Si Visual Studio lo admite, dudo que alguien use algo más.

(Siempre hay personas que intentan crear marcos de entidades y "arquitectura" que no necesitan SQL. Hasta donde yo sé, esto nunca funcionó, aunque solo sea porque el resultado es mucho más difícil de mantener y más lento).

Respondida el 13/03/2009 a las 10:35
fuente por usuario Andomar


Aquí podría ser tu PUBLICIDAD


votos
1

var q = DataContext.ExecuteQuery <Etc> ("SELECT * FROM etc") generalmente hace un trabajo bastante bueno.

Respondida el 26/03/2009 a las 12:30
fuente por usuario Adam

votos
1

Lo que está proponiendo con su clase de consulta es que todavía incrusta SQL directamente en el código de la aplicación. Lo que obtienes con la solución LINQ + ORM es que el código de la aplicación nunca contiene SQL. Todavía tiene una falta de coincidencia y una distracción de trabajar en el código. Lo mencionas en tu publicación:

Podemos probarlo en una ventana de SQL y luego simplemente cortar y pegar en nuestro código, dividiéndolo según corresponda para ingresar nuestros parámetros. No podría ser más fácil.

Lo que la sintaxis LINQ intenta darnos es consultas como ciudadanos de primera clase en el código. Sip algunas cosas son torpes, algunas cosas pueden no estar del todo bien todavía, pero el objetivo declarado de LINQ es integrar código de consulta y aplicación al punto donde no hay una disyuntiva. Parece que eso no es lo que buscas, así que quizás incrustar SQL como literales de cadena que son opacos para el compilador y el tiempo de ejecución funcionará mejor para ti. Sabemos que se puede hacer que funcione, lo hemos hecho durante años.
El otro beneficio es que la declaración LINQ no estará sujeta a las variaciones específicas del proveedor (ese es el problema del proveedor de LINQ). Podría terminar con la cadena SQL que pasa a qry.Command () vinculada a una base de datos particular.

Respondida el 13/03/2009 a las 01:47
fuente por usuario Hamish Smith

votos
1

linq2sql ha incorporado compatibilidad con paginación y está fuertemente tipado.

Puede evitar el uso del seguimiento de entidades si no lo va a usar.

Puede llamar a las funciones sql, envolviéndolas en un método.

Si utiliza el seguimiento de entidades, puede agrupar fácilmente varias llamadas de manipulación de datos (lo hace automáticamente, por lo tanto, la llamada a SubmitChanges). Entonces no golpea la base de datos 15 veces para hacer 5 inserciones y 10 actualizaciones.

También es útil cuando quieres obtener información estructurada, como:

var someInfo = from s in Context.Somethings
               select new SomeInfo
               {
                   AField = s.SomeColumn,
                   RelatedStuff = s.RelatedInfo.Where(someconditionhere)
               };

Yo diría que vale más que eso. También tenga en cuenta si realmente necesita obtener el máximo rendimiento, puede compilar expresiones y coincidirá con la velocidad del lector de datos.

Respondida el 12/03/2009 a las 08:17
fuente por usuario eglasius

votos
1

Creo que es excesivo, tanto LinqToSQL como LinqToEntities. Tomé un enfoque minimalista. Desarrollé un DAL que usa un DTO y reflexiona sobre sus propiedades para generar SQL sobre la marcha. Funciona en el 95% de los casos en que no lo necesito y no quiero pensar en SQL. Para todos los demás casos, mi DAL me permite escribir cualquier SQL que desee y devuelve un DataSet o si se le da un DTO, lo rellenará con los resultados. También permite llamar a procedimientos almacenados con el mismo concepto, devolviendo DataSet o DTO's. Funciona muy bien para mí y no necesito ver ningún SQL si no quiero.

Respondida el 12/03/2009 a las 08:09
fuente por usuario Otávio Décio

votos
0

Por el momento, no soy entusiasta de Entity Framework, pero 4.0 parece mucho mejor. No estoy seguro de que sea un cambio tan grande como Vista vs Windows 7, pero definitivamente es mejor.

Por ahora, encuentro que LINQ-to-SQL cubre la mayoría de las cosas que necesito regularmente. Diablos, incluso si solo lo uso para conectar procedimientos almacenados sin tener que escribir el código del parámetro, eso es para mi ventaja. Encuentro que las cosas de CRUD son geniales para la manipulación de datos ortogonales simples. Para escenarios más complejos, me gustan las UDF, etc., que LINQ-to-SQL admite bien.

Mientras lo ocultes en un repositorio , ni siquiera te estás arrinconando.

Re datediff - ¿has mirado SqlMethods?

Respondida el 12/03/2009 a las 10:35
fuente por usuario Marc Gravell