Cambiando a LINQ

Question

Estoy considerando pasar tiempo aprendiendo y usando LINQ to SQL, pero después de años de mejores prácticas aconsejando NO incrustar SQL, estoy teniendo dificultades para cambiar los paradigmas.

¿Por qué parece aceptado ahora incluir consultas en código compilado? Parece casi un paso atrás para mí de alguna manera.

¿Alguien ha tenido problemas con fix query/compile/deploy cycle después de cambiar a LINQ?

Creo que aún podría esperar el Entity Framework terminado.

¿Qué opinas?

Answer 1

La ventaja de Linq to Sql es que realmente no incorpora consultas en código compilado, en realidad no. La declaración de Linq significa que su código .Net en realidad tiene la lógica necesaria para construir la instrucción Sql integrada, no el Sql en bruto.

Realmente tiene mucho sentido tener un código .Net que se convierta directamente en Sql para ejecutar, en lugar de una larga lista de sprocs con documentación asociada. El modo Linq es mucho más fácil de mantener y mejorar.

No creo que cambie un proyecto existente a Linq, realmente es un reemplazo para toda la capa de datos y puede cambiar la forma en que se realiza todo el acceso a esa capa. A menos que cambie de un modelo muy similar, el costo será demasiado alto para cualquier ganancia potencial.

La potencia real de Linq to Sql está en la creación rápida de nuevas aplicaciones: le permite crear rápidamente el código de capa de datos.

Answer 2

Debe pensar en LINQ to SQL como una abstracción antes de escribir directamente SQL usted mismo. Si puede entender esto, entonces ha dado un paso en la dirección correcta. También es necesario dejar de lado algunas creencias arraigadas, como las compilaciones compiladas, que son siempre más rápidas y las cuentas SQL no deberían tener privilegios de lector/escritor de datos.

Descubrí que es posible comenzar a mover gradualmente las soluciones existentes hacia LINQ to SQL siempre y cuando haya un DAL claro en su lugar y solo esté cambiando la implementación sin afectar el contrato que pueda tener con el código de consumo. Las listas de referencias son un candidato fácil ya que son de bajo impacto, solo leen conjuntos de datos. Lo principal de lo que debe mantenerse consciente si se realizan modificaciones es el posible nombre ambiguo de las clases si ya las ha codificado manualmente para modelar la base de datos.

Con el valor de la retrospectiva de traer LINQ a SQL en una gran empresa (desde los días CTP), lo haría de nuevo en un abrir y cerrar de ojos. No es perfecto y hay problemas, pero existen enormes beneficios, especialmente en lo que respecta a la velocidad de desarrollo y la capacidad de mantenimiento. Es un nuevo paradigma y definitivamente es definitivamente un paso adelante.

Answer 3

I undertand su punto, parece que en efecto como un poco de un paso atrás ...

realidad que probablemente alejarse de LINQ a SQL y buscar más en LINQ a Entidades, sus entidades del modelo de su conceptual El modelo de datos y yo personalmente nos sentimos más cómodos al insertar consultas sobre un modelo conceptual en mi código. El modelo físico real es abstraído de usted por un marco de entidades.

Este enlace (el interior) discute LINQ a Entidades y el marco de la entidad: http://msdn.microsoft.com/en-us/library/bb386992.aspx

Este es un interesante artículo discussign los pros y los contras de ambos enfoques: http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm

Editar otro pensamiento, si no quiere esperar a EF, eche un vistazo a NHibernate, puede LINQ a eso también ... Consulte http://www.hookedonlinq.com/LINQToNHibernate.ashx

Answer 4

Hay una implementación de LINQ to SQL no solo para las bases de datos de SQL Server, por lo que Desarrollo de SQL Server Los opers también pueden aprovechar el uso de este eficiente ORM. Ya hemos agregado soporte para el nivel de consulta LaodWith() y extendimos el proceso de error. También planeamos admitir los tres modelos de herencia (TPH, TPT, TPC) y la generación de campos clave. Puede encontrar la lista de bases de datos compatibles here

Answer 5

No considero que incruste SQL en su código más de lo que es incrustar un nombre de Proc almacenado en su código. En la mayoría de los casos, un cambio en su Proc implica cambiar su código de todos modos. Por ejemplo, generalmente necesita agregar un nuevo parámetro de entrada/salida o actualizar un método getter/setter para hacer referencia a una nueva columna.

Lo que hace es eliminar una gran cantidad de trabajo de escribir dos veces más código para alinear propiedades y métodos en su código con procs y columnas en su base de datos.