2009-10-03 671 views
5

He estado utilizando ADO.NET a favor de LINQ to SQL (o Entidades) hasta este punto. Estoy empezando un nuevo proyecto que debería ser pequeño, al menos al principio, pero me gustaría tener espacio para expandirme más adelante.¿Es una mala idea saltar a LINQ to SQL ahora?

Siento que ahora es un buen momento para entrar en LINQ. Lo he evitado por bastante tiempo; sin embargo, me preocupa la dirección actual de LINQ to SQL. Escuché que LINQ to Entities va a ser el acceso de datos preferido de MS en el futuro. Prefiero no entrar en LINQ to Entities porque: 1.) Probablemente una curva de aprendizaje más empinada que no quiero incluir en la mezcla en este momento (ya estoy ocupado aprendiendo MVC) y 2.) Escuché que no está lista para hora estelar.

Mi preocupación es esta: si empiezo un proyecto con LINQ to SQL ahora, ¿puedo actualizarlo fácilmente a LINQ a Entities en el futuro?

Respuesta

11

LINQ to Entities está listo para el horario estelar, y no necesariamente mucho más empinado para aprender. Sin embargo, LINQ to SQL también está bien, aprenderá mucho que seguirá siendo útil a medida que avanza.

En resumen, elija lo que mejor se adapte al proyecto. Si SQL Server es y seguirá siendo la plataforma de DB, y si no hay necesidad de reasignar tablas u otros trucos sofisticados, LINQ to SQL lo llevará allí muy rápido. También es muy eficiente.

+4

LINQ to SQL también es una buena opción si disfruta sin pensar reconstruyendo su archivo .dbml cada vez que realiza un cambio en su base de datos. –

+1

@James Jones No si está utilizando algo como PLINQO – CitizenBane

+1

.... o http: //www.huagati.com/dbmltools/- le permite usar el diseñador de L2S listo para usar, pero agrega sincronización verdadera de "solo cambios", convenciones de nombres, comentarios de doc. Xml, generación de scripts SQL-DDL diff de modelos L2S, etc. – KristoferA

0

Microsoft emitió una declaración de que LINQ to SQL ha llegado al final de su vida útil y ya no proporcionará ninguna mejora importante. Echa un vistazo a su declaración oficial recubierta de azúcar here. El Marco de la Entidad tomará su lugar.

Here is the MSDN article sobre cómo trasladar un proyecto de LINQ to SQL a Entity Framework.

+1

No lo mejorarán, pero tampoco se lo quitarán. De hecho, lo mismo es cierto para Windows Forms, no significa que no deba usarlo. –

+3

Winforms tuvo una oportunidad de madurar antes de que WPF tomara las riendas. LINQ to SQL, por otro lado, es relativamente nuevo. –

+0

¿Pero eso significa que no deberías volver a usarlo? Lo que funciona ahora continuará funcionando en el futuro, y aunque MS no le agregará nuevas características, aún lo apoyará en términos de correcciones (creo que algunas correcciones vendrán con .NET 4.0). – JulianR

4

Si su aplicación entra en producción antes de que .net 4.0 SP1 esté disponible, vaya a L2S. Linq-to-SQL es estable, no desaparecerá en el corto plazo y genera un gran SQL. EF v1 no. Período. Consulte MSDN EF forum si desea saber más sobre las enfermedades infantiles EFv1.

Si EFv2 estará a la altura de la tarea queda por ver; Solo he usado beta 1 y esa no tiene algunas de las mejoras que se dice que tienen las versiones posteriores.

El tema "L2S vs EF" se ha cubierto numerosas veces ya, echa un vistazo a:
Is LINQ to SQL Dead or Alive?

... y personalmente, creo que la declaración de Anders Hejlsberg a Redmond desarrollador de noticias hace que sea lo suficientemente claro. "LINQ to SQL no está muerto. Te puedo asegurar que no está muerto. Nada desaparece. Nunca lo hemos hecho y nunca lo haremos,", dijo.

http://reddevnews.com/blogs/desmond-file/2008/12/digital-darwinism.aspx

0

Las personas que dicen LinqToSql tiene una curva de aprendizaje mínima no están siendo completamente honesto con usted. ADO.NET tiene una curva de aprendizaje significativa. Cualquier ORM tiene una curva de aprendizaje significativa. Una vez que haya usado un ORM, no es demasiado difícil elegir otro ORM. Una vez que haya creado su propio ORM (por diversión, no lo haga de verdad), realmente obtendrá lo que está pasando.

Linq (no estoy hablando de LinqToSql) es una gran tecnología y no puede usar Linq con ADO.NET, necesita algo como un ORM.

Por muchas razones (siendo Linq una de las más fuertes, la madurez de ORM es otra), ahora es un buen momento para pasar de ADO.NET a un ORM.

Por lo que he visto, "actualizar" un proyecto de un ORM a otro (no importa qué ORM) es siempre difícil, a menos que realmente sepa lo que está haciendo y mantenga su ORM como poco acoplado de todo lo demás como sea posible.

Me gustaría tener tanto LinqToSql como EntityFramework (también conocido como LinqToEntities). Ambos carecen de algunas características que probablemente necesitarás en el "mundo real". Ninguno de los dos está maduro o probado (como lo demuestran los desacuerdos que ha visto en las respuestas a esta pregunta).

Existen ORM maduros y probados en el espacio .NET y no es muy difícil determinar cuál es el que domina en este momento.

+0

La crítica de Entity Framework en esta respuesta está relacionada con EF 1.0/3.5. EF 4 es más que suficiente como un ORM. –

0

Es posible que LINQ to SQL esté optimizado para el servidor SQL, ya que puede ser una mejor opción para su problema que Entity Framework.

Sin embargo, a la larga, debe considerar cuánto tiempo se espera que viva su aplicación y cuál sería el costo de la "actualización".

0

Me he mantenido al margen de los ORM de Microsoft y estoy contento de haberlo hecho. Hay un ciclo constante de exageración -> aceptación -> realización de debilidades & defectos -> fin de la vida, comienza de nuevo.

No me malinterpreten, soy un gran admirador de .Net, pero no de los ORM de Microsoft. Hay mejores soluciones por ahí.

Me doy cuenta de que esto es solo opinión, pero lo ofrezco por lo que vale.