¿Aprender LinqToSql o seguir con ADO.NET?

Question

Estoy debatiendo qué tecnología utilizar para un próximo proyecto de ASP.NET.

Supuestos:

• Yo estaré usando Visual Studio 2008 SP1 (.NET Framework 3.5)
• El back-end habrá una base de datos SQL Server 2005 (o posiblemente 2008)
• El código se escribirá en C#
• Ya tengo experiencia con LinqToObjects y LinqToXml
• También tengo experiencia con ADO.NET y algunas bibliotecas ya compiladas
• El proyecto es relativamente pequeña
• La página web contará con unos cinco pantallas
• La base de datos tendrá quizás seis o siete mesas
• Habrá tal vez 25-50 usuarios activos
• transacciones por día probablemente lo hará ser aproximadamente 5-10 tops
• datos personales mínimos serán almacenados
• las consecuencias del fracaso o el sitio ser atacado sería mínimo

Opciones: procedimientos almacenados

1. escribir y los llaman con ADO.NET. Todavía puedo usar LinqToObjects una vez que termine de llenar mi DataSet.

2. Aproveche lo que sé de Linq para aprender LinqToSql.

Análisis:

que ya sé cómo hacer la opción 1, pero que realmente me gusta usar LINQ exclusivamente. El problema con la opción 2 es que, de acuerdo con todo lo que he leído, LinqToSql probablemente estará en desuso en favor de Entity Framework.

Preguntas:

1. ¿Cómo es la empinada curva de aprendizaje para LinqToSql si ya está familiarizado con otras tecnologías de Linq?

2. ¿Vale la pena invertir cualquier tiempo en el aprendizaje de LinqToSql, dado que es posible que Microsoft no lo haya desarrollado aún más?

3. ¿Entenderá LinqToSql algún día me ayudará a comprender Entity Framework o son demasiado diferentes?

4. En última instancia, ¿qué opción recomendaría para mi situación?

Actualización:

no quiero que esto se pierda en los comentarios: marc_s señalaron que LinqToSql es están desarrollando aún más, por lo menos a partir de .NET 4.0. Enlace: http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40.

No sé si esto significa que LinqToSql tiene un futuro después de todo, pero sí hace que el aprendizaje de esa tecnología sea un poco más atractivo.

Una cosa que no pregunté en mi publicación original, pero debería haber sido: ¿Es probable que las fallas en Entity Framework afecten a este proyecto?

Gracias por las respuestas hasta el momento.

Análisis adicional

Aquí está una lista de inconvenientes LinqToSql, sobre la base de algunos de los comentarios a continuación:

1. debe actualizar continuamente las tablas y objetos en el diseñador cuando se realizan cambios a la base de datos subyacente. No hay forma de "actualizar" o "sincronizar" para que reconozca automáticamente los cambios.
2. El control de versiones se complica por el hecho de que el diseñador no genera los archivos subyacentes en un orden consistente.
3. El diseñador LinqToSql genera código diferente de SqlMetal.
4. Existen problemas/errores relacionados con la carga ansiosa.

De estos, el elemento 1 es la mayor preocupación para mí. Incluso con un proyecto pequeño, el cambio es inevitable. Recuerdo que una vez traté de usar el diseñador de Windows Forms para mapearlo en una base de datos, y me explotó en la cara tantas veces que lo abandoné a favor de lanzar mis propias clases de ayuda de ADO.NET.

Sin embargo, parece que SqlMetal podría ser capaz de manejar mis necesidades perfectamente. Ejecuto un comando, regenera todo desde cero desde la base de datos, he terminado. Si mantengo mi base de datos simple (solo tablas, sin procedimientos almacenados, vistas o funciones), quizás SqlMetal es todo lo que necesitaré.

Answer 1

LINQ to SQL es bastante sencillo si ya sabe LINQ to XML u objetos ("objetos" Linq son sólo "listas") ...

LINQ to SQL no está en desuso por Microsoft, que sólo sugieren que ve con EF. No será actualizado.

Linq To Sql se podía ver casi como EF. Con EF puede hacer cosas más complicadas, pero en el nivel base es casi lo mismo (para su sitio con 7 tablas no hace ninguna diferencia).

Para su situación, sugiero que vaya con LINQ. Es divertido y más rápido que SP + ADO.NET. Usar un ORM en la actualidad es casi una buena elección. No usarlo debería ser la excepción (para mí).

Answer 2

Estoy de acuerdo con Davide Vosti, pero es posible que desee considerar otras opciones, como NHibernate (que también tienen soporte LINQ).

La versión actual de EF no es impresionante: crea realmente desagradable T-SQL que lleva mucho tiempo en ejecutarse.

Actualmente estamos usando EF, pero esta es la última vez que elegiré EF para .NET 3.5. Le estoy dando una oportunidad más en .NET 4, pero a menos que mejore drásticamente, elegiré otras opciones (y LINQ to SQL no será uno de ellos).

Answer 3

1 - ¿Qué tan empinada es la curva de aprendizaje de Linq-to-Sql si ya está familiarizado con con otras tecnologías Linq?

Yo diría que ha abordado quizás el 50% de la curva de aprendizaje, pero puede ser más o menos, estoy adivinando. Hay mucho más en LinqToSql que solo Linq.

2 - ¿Vale la pena invertir tiempo en aprender LINQ to SQL dado que puede no ser desarrollado por Microsoft?

Existen ventajas para aprender cualquier ORM. Si iba a aprender un ORM, LinqToSql probablemente sería # 3 o # 4 en mi lista. La comunicación de Microsoft sobre el futuro de LinqToSql ha sido turbia en el mejor de los casos y obviamente están haciendo un gran esfuerzo para que EntityFramework siga avanzando. Microsoft siempre puede cambiar de opinión y tiene que llegar a sus propias conclusiones.

3 - ¿Entenderá Linq-To-Sql algún día me ayudará a entender Entity Framework o son demasiado diferentes?

Todos los ORM comparten características similares y el aprendizaje de cualquier ORM lo ayudará a comprender otros ORM. LinqToSql en realidad comparte una serie de las mismas características y desventajas que EntityFramework, por lo que hay más similitudes de las que cabría esperar. Dicho esto, recomendaría aprender EntityFramework antes de LinqToSql.

4 - En última instancia, ¿qué opción recomendaría para mi situación?

El mejor ORM para .NET 3.5 en la gran mayoría de las situaciones es claramente NHibernate. NHibernate es compatible con Linq, pero lo admite de forma diferente a los ORM de Microsoft. Dicho esto, no ha dado una razón que claramente haría NHibernate superior a ADO.NET para su situación. No recomendaría ni LinqToSql ni EntityFramework para su situación.

Answer 4

1. ¿Cómo de empinada es la curva de aprendizaje para LinqToSql si ya está familiarizado con otras tecnologías Linq?

Para el alcance del proyecto que ha definido, debe ser mínimo. Hacer las cosas simples es muy simple, los conceptos más avanzados requieren un poco de conocimiento de cómo funciona bajo el capó, pero una vez más, nada que rompa la tierra.

2.Is que vale la pena invertir tiempo en aprender LinqToSql dado que puede no ser desarrollado por Microsoft?

Yo diría que sí, no es difícil de aprender si ya usas las técnicas de Linq. Además, Microsoft continuará apoyando y desarrollando Linq2Sql como lo señaló marc_s. Scott Hanselman utiliza Linq2Sql para su proyecto Cena del empollón (http://nerddinner.codeplex.com/)

comprensión 3.Will LinqToSql ayudarme de algún día comprender Marco de la entidad o son> demasiado diferentes?

He usado mucho de Linq2Sql y solo un pedacito de Entity Framework, son similares pero diferentes. Los conceptos básicos son muy parecidos, y no he estado involucrado en ningún caso de uso súper avanzado.

4. Inicialmente, ¿qué opción recomendaría para mi situación?

Si estuviera desarrollando un sitio como usted propuso, me gustaría ver seriamente en Linq2Sql, que probablemente podría obtener las bases de trabajo en unas pocas horas y tomar una decisión si la curva de aprendizaje es mayor de lo que quiere tratar con . (En mi humilde opinión, dudo que encuentre que es el caso.)

Answer 5

Eche un vistazo a Subsonic, se encuentra en un buen término medio de facilidad de uso de Linq a SQL y NHibernate.

con subsónicos, usted obtiene algunas de las agradables características de NHibernate tales como el primer desarrollo del modelo, la generación automática de esquemas de base de datos y el soporte para bases de datos que no sean Sql Server.

También hay un buen comparison page que enumera las diferencias entre los tres ORMS