¿Debo comenzar a usar LINQ to SQL?

Question

Actualmente estoy usando NetTiers para generar mi capa de acceso a datos y capa de servicio. He estado usando NetTiers por más de 2 años y lo he encontrado muy útil. En algún momento necesito ver LINQ para que mis preguntas sean ...

1. ¿Alguien más ha pasado de NetTiers a LINQ to SQL?
2. ¿Este cambio fue algo bueno o malo?
3. ¿Hay algo que deba tener en cuenta?
4. ¿Recomendarías este interruptor?

Básicamente me gustaría recibir cualquier pensamiento .

Answer 1

1. Sin
2. Ver # 1
3. Se debe tener cuidado de los gastos generales abstracción estándar. También es muy SQL Server basado en su estado actual.
4. ¿Está utilizando SQL Server, entonces quizás? Si está utilizando LINQ para otras cosas en este momento, como datos XML (excelentes), datos Object, Datasets, entonces sí, debería cambiar para tener una sintaxis de datos uniforme para todos ellos. Como lagerdalek mencionado si no está roto, no lo arregles. A partir del vistazo rápido al .NETTiers Application Framework, diría que si ya tiene una inversión con esa solución, parece que le ofrece mucho más que una simple capa de acceso a datos y debe seguir con ella.

De mi experiencia LINQ to SQL es una buena solución para proyectos de tamaño pequeño-mediano. Es un ORM que es una gran manera de mejorar la productividad. También debería darle otra capa de abstracción que le permitirá cambiar la capa debajo de otra cosa. El diseñador en Visual Studio (y creo que VS Express también) es muy fácil y simple de usar. Le da la edición común de arrastrar y soltar y propiedad de las asignaciones de objetos.

@Jason Jackson - El Diseñador le permite agregar propiedades a mano, sin embargo, necesita especificar los atributos para esa propiedad, pero puede hacerlo una vez, puede tomar 3 minutos más que el arrastre inicial de la tabla en el diseñador Sin embargo, solo es necesario una vez por cambio en la base de datos. Esto no es muy diferente de otros ORM, sin embargo, tiene razón en que podrían hacer esto mucho más fácil, y encontrar solo aquellas propiedades que han cambiado, o incluso implementar algún tipo de herramienta de refactorización para tales necesidades.

Recursos:

• Why use LINQ to SQL?
• Scott Guthrie on LINQ to SQL
• 10 Tips to Improve your LINQ to SQL Application Performance
• LINQ To SQL and Visual Studio 2008 Performance Update
• Performance Comparisons LINQ to SQL/ADO/C#
• LINQ to SQL 5 Minute Overview

Tenga en cuenta que Parallel LINQ se está desarrollando para permitir un rendimiento mucho mayor en máquinas con núcleos múltiples.

Answer 2

NetTiers es muy bueno para generar un DAL pesado y robusto, y lo usamos internamente para bibliotecas y marcos principales.

Tal como lo veo, LINQ (en todas sus encarnaciones, sino específicamente como creo que está pidiendo a SQL) es fantástico para el acceso de datos rápida, y generalmente lo usamos para los casos más ágiles.

Ambas tecnologías son bastante inflexibles para cambiar sin la regeneración del código o la capa de dbml.

Dicho esto, se usa adecuadamente LINQ 2 SQL es una solución bastante robusta, e incluso podría comenzar a usarla para su futuro desarrollo debido a su facilidad de uso, pero no descartaría su DAL actual por ella, si no está roto ...

Answer 3

Mi experiencia me dice que al usar linq puedes hacer las cosas más rápido, sin embargo, las acciones reales en la base de datos son más lentas.

Entonces ... si tiene una base de datos pequeña, le diré que lo haga. Si no, esperaría algunas mejoras antes de cambiar

Answer 4

Intenté usar Linq en SQL en un proyecto pequeño, pensando que quería algo que pudiera generar rápidamente. Me encontré con muchos problemas en el diseñador. Por ejemplo, cada vez que necesite agregar una columna a una tabla, básicamente tendrá que eliminar y volver a agregar la definición de la tabla en el diseñador. Si ha establecido alguna propiedad en la tabla, entonces debe volver a establecer esas propiedades. Para mí, esto realmente ralentizó el proceso de desarrollo.

LINQ to SQL en sí es bueno. Realmente me gusta la extensibilidad. Si pueden mejorar el diseñador, podría intentarlo de nuevo. Creo que el marco se beneficiaría de un poco más de funcionalidad dirigida a un modelo desconectado como el desarrollo web.

Consulte Scott Guthrie's LINQ to SQL series de publicaciones en el blog para obtener algunos buenos ejemplos de cómo usarlo.

Answer 5

Estoy usando LINQ to SQL en proyectos bastante grandes en este momento (unas 150 tablas) y me está resultando muy bien. El último ORM que utilicé fue IBatis y funcionó bien, pero requirió mucho trabajo de campo para realizar sus asignaciones. LINQ to SQL funciona muy bien para mí y hasta ahora ha demostrado ser muy fácil de usar de forma inmediata. Definitivamente hay algunas diferencias que debe superar en la transición, pero recomendaría su uso.

Nota al margen, nunca he usado o leído acerca de NetTiers, así que no descontaré su efectividad, pero LINQ to SQL en general ha demostrado ser un ORM extremadamente viable.

Answer 6

Nuestro equipo solía utilizar NetTiers y lo encontró útil. PERO ... cuanto más lo usamos, más encontramos dolores de cabeza y dolor con él. Por ejemplo, cada vez que realice un cambio en la base de datos, es necesario volver a generar el DAL con CodeSmith que implicó:

• re-generación de miles de líneas de código en 3 proyectos separados
• re-generación de cientos de procedimientos almacenados

Quizás haya otras maneras de hacerlo, pero esto es lo que teníamos que hacer. La regeneración del código fuente estaba bien, daba miedo, pero está bien. El problema real vino con los procedimientos almacenados. No eliminó ningún procedimiento almacenado no utilizado, de modo que si eliminó una tabla de su esquema y generó su DAL, los procedimientos almacenados para esa tabla no se eliminaron.Además, esto se convirtió en un gran dolor de cabeza para las secuencias de comandos de cambio de base de datos donde tuvimos que comparar la estructura de la base de datos anterior a la nueva y crear un script de cambio para actualizar las instalaciones del cliente. Esta secuencia de comandos podría ejecutar en las decenas de miles de líneas de código sql y si había un problema para ejecutarlo, que invariablemente era, fue un gran problema para resolverlo.

Luego se encendió la luz, NHibernate como ORM. Ciertamente tiene un tiempo de aceleración pero vale la pena. Hay un montón de soporte para él, así que si hay algo que necesita hacer, más que probable que se haya hecho antes. Es extremadamente flexible y le permite controlar cada aspecto de la misma y algo más. También es cada vez más fácil de usar. Fluent Nhibernate es una gran forma de deshacerse de los archivos de mapeo xml que se necesitan y NHibernate Profiler proporciona una excelente interfaz para ver lo que ocurre detrás de las escenas para aumentar la eficiencia y eliminar la redundancia.

Pasar de NetTiers a NHibernate ha sido doloroso, pero en el buen sentido. Nos ha obligado a avanzar hacia una mejor arquitectura y reevaluar las necesidades funcionales. NetTiers proporcionó toneladas de código de acceso a datos, obtenía esta entidad por su id, obtenía esta otra entidad por su clave externa, obtenía una tlist y una lista vlist de esto y aquello, pero la mayor parte era innecesaria y no utilizada. NHibernate con un repositorio genérico y repositorios personalizados solo donde fuera necesario redujo toneladas de código no utilizado y realmente mejor legibilidad y confiabilidad.