¿Está desaprobado LINQ to SQL?

Question

A finales de 2008 hubo un gran debate sobre el futuro de LINQ to SQL. Muchos sugirieron que las inversiones de Microsoft en Entity Framework en .NET 4.0 eran una señal de que LINQ to SQL no tenía futuro. Pensé que esperaría antes de tomar una decisión, ya que la gente no estaba de acuerdo.

Avance rápido 18 meses y tengo proveedores que brindan soluciones que dependen de LINQ a SQL y personalmente lo he probado y realmente he disfrutado trabajando con él. Pensé que estaba aquí para quedarse.

Pero estoy leyendo un nuevo libro (C# 4.0 How-To de Ben Watson) y en el capítulo 21 (LINQ), sugiere que "ha sido más o menos obsoleto por Microsoft" y sugiere usar LINQ to Entity Marco de referencia.

Mi pregunta es si o no LINQ a SQL está en desuso oficialmente y/o si las entidades autorizadas (Microsoft, Scott Gu, etc.) sugieren oficialmente el uso de LINQ a Entidades en lugar de LINQ a SQL.

Answer 1

Para todas las personas "LINQ a SQL ha muerto": el propio Scott Guthrie menciona claramente en TechEd Europa que LINQ to SQL es totalmente compatible en .NET 4, y la Guardia Damien registró una blog post en lo cambios y mejoras se han hecho para LINQ to SQL en .NET 4.

para citar a Mark Twain: "Los informes de mi muerte han sido muy exagerados" ......

Answer 2

No, no lo es. El equipo todavía está trabajando para mejorarlo.

Answer 3

Asegúrese de tener un vistazo a this article publicado en InfoQ.com - es realmente interesante. Su conclusión: "[O] ver el largo plazo LINQ to SQL y LINQ to Entities se fusionarán. Mientras tanto, el trabajo de desarrollo en LINQ to SQL no terminará por completo".

Answer 4

supongo que es inevitable que se fusionen. EF es realmente una implementación a nivel empresarial de LINQ sobre objetos db. linq2sql era, en todos los sentidos, una prueba de concepto (y mucho más) que en realidad aumentó las piernas pero alimentó muchas de las ideas que ahora vemos en EF. al final del día, la capa DAL (nhibernate, EF, l2s, subsónico, etc.) debería estar muy abajo en la cadena para negar cualquier diferencia en el código BO del cliente que implemente el servicio LINQ - el intercambio en caliente sería el final juego a través de DI.

Answer 5

Última revisión, este mismo sitio usa (o solía usar) Linq To SQL. Joel Spolsky lo menciona en su GoogleTechTalk: http://www.youtube.com/watch?v=NWHfY_lvKIQ.

Cuando se habla de software, "muerto" es un modificador figurativo (el software no muere en ningún sentido literal, biológico), por lo que este debate puede prolongarse mientras las partes involucradas se niegan a definir en sentido literal significa para "Linq To Die". O, LTD para abreviar. Por lo tanto, a partir de este momento, el debate de LTD ha persistido durante dos años. Todo por una pequeña ambigüedad lingüística.

Los que dicen que "L2S está muerto" generalmente se refieren al hecho de que L2S no recibirá demasiadas (si las hay) funciones nuevas. Es probable que las actualizaciones de Linq (como las actualizaciones mencionadas en Damien Guard's post) se limiten a actualizaciones de rendimiento, usabilidad y estabilidad. Por supuesto, algunos desarrolladores podrían argumentar que esto es algo bueno (probablemente los mismos desarrolladores que están un poquito enojados por el new dynamic type).

Los que dicen que "L2S no está muerto" generalmente se refieren al hecho de que L2S no se va a cortar por completo de .Net (al menos no pronto). Piensa: ADO.Puede perder algo de su tracción entre los desarrolladores en ejercicio (y ese puede ser el deseo tácito de esas personas astutas en Microsoft), pero eso no significa que no podrá usar L2S si así lo desea. Simplemente significa que Microsoft no intenta tentar a las masas con eso.

Al comenzar un proyecto, realmente creo que es genial poder elegir entre EF y L2S. Como Bill Wagner points out , hay un momento y un lugar para ambos.

Answer 6

llego tarde a esta discusión, pero quería señalar que ya en 2008, el enlace a SQL Project Manager (Tim Mallalieu) hizo este anuncio en su blog post,

"A partir de .NET 4.0, LINQ to Entities [en lugar de LINQ to SQL] será la solución de acceso a datos recomendada para LINQ para escenarios relacionales ".

No he encontrado otros anuncios más recientes en sentido contrario.