.net - transact - linqpad sql to linq

¿Qué hay de malo con Linq en SQL? (11)

¿Qué hay de malo con Linq en SQL?

O bien, ¿qué pasa con Linq to SQL que lo haría inadecuado para un proyecto, ya sea nuevo o existente? Quiero saber por qué no elegiría Linq para SQL para un proyecto en particular, incluidos los parámetros del proyecto que lo hacen inadecuado.

Bueno, he desarrollado algunas aplicaciones usando LINQ to SQL. Uno de los principales problemas que encuentro es tener que aplicar capas a su aplicación. En LINQ to SQL, las clases de entidad están muy relacionadas con el código de acceso a datos. Además, hay algunos problemas con DataContext, lo que significa que puede usar un objeto DataContext para recuperar un elemento, pero no puede transferir el elemento (objeto) a otro DataContext (al menos no fácilmente).

LINQ to SQL será útil si no te importa aplicar capas a tu aplicación correctamente y también si lo único que deseas es crear una aplicación de manera rápida, también conocida como desarrollo de aplicaciones RAPID.

Para un proyecto que necesita hacer uso de bases de datos que no sean SQL Server:

1) Estás bloqueado para usar SQL Server

Para un proyecto con relaciones de entidades complejas y / o relaciones que cambian gradualmente a lo largo del tiempo:

2) Estás bloqueado en el mapeo 1 a 1 de tablas a clases

Para un proyecto que debe usar versiones 1.x de .NET

3) No funcionará con .NET 1.x

Una gran ventaja de LINQ-to-SQL proviene de supuestamente ser capaz de construir consultas de datos directamente en su código subyacente basado en objetos de datos consultables / enumerables fuertemente tipados de su dbml (que desempeña el papel de un DAL muy limitado) . Por lo tanto, como ya se mencionó, una consecuencia es que te alienta a jugar fuera de las capas o niveles fuertemente definidos y separados de tu aplicación.
Para contrarrestar ese punto, debería significar que debería poder eliminar la mayor parte o la totalidad de la lógica de negocios que estaba escribiendo en los procedimientos almacenados en la base de datos, de modo que al menos solo tiene que ir al código que trata con los datos para cambie las reglas comerciales que no afectan al esquema ... Sin embargo, eso se rompe un poco cuando se da cuenta de lo complicado que puede ser escribir una consulta con una combinación externa con agregados con agrupación, al menos cuando se acerca por primera vez. Por lo tanto, tendrá la tentación de escribir los sprocs en el SQL que sabe que es tan simple y bueno para hacer esas cosas en lugar de perder el tiempo tratando de descubrir la sintaxis de LINQ para hacer lo mismo cuando solo va a convertirlo a feo código SQL de todos modos ...
Habiendo dicho eso, realmente me encanta LINQ, y mi aprecio por él aumentó enormemente cuando comencé a ignorar este sentimiento de "sintaxis de consulta es más fácil de leer" que he visto flotando y cambiado a la sintaxis del método. Nunca miró hacia atrás.

porque no estás usando 3.5 ... ¿es esa una respuesta válida?!?!?

Es difícil burlarse mientras se prueban las unidades debido a la falta de una interfaz en la clase System.Data.Linq.DataContext . Aquí hay un posible enfoque: Mocking LINQ to SQL DataContext .

Lo único que etiquetaría como un "showtopper" técnico es si desea utilizar otros RDBMS que SQL Server. (aunque se puede solucionar: ver el blog de Matt Warren en http://blogs.msdn.com/mattwar/ )

Además de eso, hay algunos pros y contras que ya figuran en las respuestas anteriores a su pregunta. Sin embargo, todos los aspectos negativos mencionados hasta ahora tienen soluciones provisionales por lo que no son realmente increíbles.

Un showtopper no técnico [potencial] es el riesgo de que MSFT lo abandone a favor de EF ... Más sobre eso aquí: http://oakleafblog.blogspot.com/2008/05/is-adonet-team-abandoning- linq-to-sql.html

Aunque (en mi opinión,) el estado actual de EF es motivo suficiente para que continúen trabajando en L2S. Así que esperemos que lo hagan ...

No hay forma de mezclar y combinar carga lenta / carga ansiosa en un contexto de datos.
La verdadera ignorancia de la persistencia es muy difícil.
Las opciones de mapeo son limitadas. Por ejemplo, no hay relaciones de muchos a muchos.
La resincronización de la asignación con cambios de esquema es dolorosa.

A pesar de todo lo anterior, creo que linq-to-sql es una excelente opción para muchos proyectos.

No es muy adaptable a los cambios en el esquema de la base de datos. Debe reconstruir la capa de dbml y regenerar sus contextos de datos.

Al igual que cualquier ORM (no estoy entrando en el debate sobre si se trata de un ORM o no), debe tener en cuenta qué SQL se está generando y cómo eso influirá en sus llamadas.

Los insertos no están agrupados, por lo que puede tener un alto costo en rendimiento.

Se está poniendo a punto a favor del Marco de la Entidad

A pesar de que está utilizando un modelo de proveedor que permitirá que los proveedores se creen para otras plataformas DBMS, solo se admite SQL Server.

[ EDIT @ AugustLights - En mi experiencia:] La carga lenta puede llevar un poco de piratería para funcionar.

Una vez dicho esto, creo que es muy útil si se usa correctamente

Un verdadero ORM debe separar el diseño de sus entidades comerciales de su medio de persistencia. De esta forma, puede refactorizar cualquiera de ellos por separado y solo tiene que mantener el mapeo entre los dos. Esto reduce la cantidad de código lógico de la aplicación que necesita mantener para los cambios en la base de datos.

Para lograr este tipo de enfoque agnóstico de persistencia con Linq-to-SQL, tendría que usar sus clases generadas en DTO y mantener una lógica de mapeo entre sus DTO y sus Entidades.

Hay muchos ORM mejores para tomar este enfoque (como NHibernate) que reducen en gran medida la necesidad de DTO.

Esta pregunta fue hecha una vez antes aquí . Pero, en esencia, LINQ to SQL genera planes de ejecución subóptimos en su base de datos. Para cada longitud de parámetro diferente que busque, forzará la creación de un plan de ejecución diferente. Esto eventualmente obstruirá la memoria en su base de datos que se está utilizando para almacenar en caché los planes de ejecución y comenzará a caducar las consultas anteriores, que deberán volver a compilarse cuando vuelvan a aparecer.

Como mencioné en la pregunta a la que me he vinculado, es una cuestión de lo que estás tratando de lograr. Si está dispuesto a cambiar la velocidad de ejecución por la velocidad de desarrollo, LINQ to SQL podría ser una buena opción. Si le preocupa la velocidad de ejecución, hay otros ORM / DAL / soluciones disponibles que pueden tardar más tiempo en trabajar, pero le proporcionarán pruebas futuras contra cambios de esquema y soluciones de mejor rendimiento a costa de una sobrecarga de desarrollo adicional.

No parece tener ningún soporte para los valores predeterminados en las columnas DB.