¿Qué pasa con Linq to SQL?¿Qué pasa con Linq a 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é llamaría no elija Linq a SQL para un proyecto en particular, incluidos los parámetros del proyecto que lo hacen inadecuado.
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 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.
Está siendo sunsetted a favor de la Entidad marco
A pesar del hecho de que está utilizando un modelo de proveedor que permitirá a los proveedores que se construirán para otras plataformas DBMS, sólo es compatible con SQL Server.
[EDITAR @ AugustLights - En mi experiencia:] La carga diferida puede tomar un poco de piratería para conseguir trabajo.
Dicho esto, creo que es muy útil si se utiliza correctamente
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 le importa aplicar capas a su aplicación correctamente y también si todo lo que desea es crear una aplicación de manera rápida, también conocida como Desarrollo de aplicaciones RAPID.
No incluye todo lo necesario para transferir objetos de una CC a otra incorporada. Sin embargo, eso se puede agregar fácilmente: consulte la clase "LinqSync" al final de este artículo: http://blog.huagati.com/res/index.php/2008/06/23/application-architecture-part-2 -data-access-layer-dynamic-linq/ – KristoferA
Me importa 'aplicar capas a mi aplicación correctamente' y todavía me gusta linq-to-sql. – liammclennan
Una gran cantidad de la ventaja de LINQ a SQL proviene de supuestamente ser capaz de construir consultas de datos de la derecha en su código subyacente basado en objetos de datos consultables/enumerables fuertemente tipificados 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, entonces al menos solo tiene que ir al código que trata con el datos para cambiar las reglas comerciales que no afectan al esquema ... Sin embargo, eso se rompe un poco cuando te das cuenta de lo complicado que puede ser escribir una consulta con una combinación externa con agregados con agrupación, al menos cuando te acercas 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 ...
Dicho esto, realmente me encanta LINQ, y mi estima por ello 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.
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.
Ah, pero entonces, no hay ninguna burla disponible para el Procedimiento almacenado. – Graviton
Acabo de pasar un día tratando de burlarme de la Tabla
porque no está utilizando 3.5 ... ¿es esa una respuesta válida?!?!?
Diría que es válido: las limitaciones del marco son negativas. –
Válido, pero no tan interesante. – Will
Para un proyecto que tiene que hacer uso de bases de datos que no sean de SQL Server:
1) Te bloqueado para el uso de SQL Server
Para un proyecto con las relaciones de entidades complejas y/o relaciones que cambian gradualmente con el tiempo:
2) Se está bloqueado para el 1-a-1 mapeo de tablas a las clases
para un proyecto que debe utilizar versiones 1.x de .NET
3) No funcionará con .NET 1.x
No funcionará para .NET 2.x tampoco, AFAIK. Pensé que solo era 3.5 ... –
Esta pregunta se realizó una vez antes de over here. 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.
Soy escéptico de esta respuesta. ¿Cuál es su fuente o hay alguna manera en que pueda justificar esta conclusión? – liammclennan
que solía ser el caso pre-RTM (es decir, en versiones beta). Ya no es el caso, ya que se arregló antes de que fuera RTM. – KristoferA
El origen de esto se puede encontrar aquí: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290 –
A pesar de todo lo anterior, creo que linq-to-sql es una excelente opción para muchos proyectos.
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 @http://blogs.msdn.com/mattwar/)
Además de eso, hay algunas ventajas y desventajas que ya se mencionaron 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.
A [potencial] no técnica sensacional es el riesgo de que MSFT lo abandonará en favor de EF ... Más sobre esto 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 razón suficiente para que continúen trabajando en L2S. Así que esperemos que lo hagan ...
Es doesn't appear to have cualquier soporte para valores predeterminados en columnas de DB.
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 de persistencia independiente con Linq-to-SQL, tendría que usar sus clases generadas en DTO y mantener una lógica de asignación entre sus DTO y sus Entidades.
Existen ORM mucho mejores para adoptar este enfoque (como NHibernate) que reducen en gran medida la necesidad de DTO.
¿Qué tal si no estás usando el diseñador o code-gen? El mapeo se puede hacer a través de atributos o configuración XML - respondiendo a un cambio en el esquema en este caso con Linq a SQL sería similar a otros ORM, ¿no? –
Créeme, Erik, no quieres hacer el mapeo manualmente. Hay demasiados atributos que necesita establecer. Oh, una cosa más El diseñador de LINQ to SQL tiene muchos errores. – azamsharp
Muy cierto, pero el típico usuario de LINQ to SQL no estaría pirateando el XML, pero es cierto, al igual que las limitaciones de LINQ 2 SQL y EF en la experiencia del diseñador – johnc