query - ¿LINQ to SQL está en desuso?
linq to entities join (6)
Asegúrese de echar un vistazo a este artículo 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".
A fines 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.
Avanzamos 18 meses y tengo proveedores que brindan soluciones que dependen de LINQ to 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 Framework.
Mi pregunta para usted es si LINQ to SQL está o no oficialmente desaprobado y / o si las entidades autorizadas (Microsoft, Scott Gu, etc.) sugieren oficialmente el uso de LINQ para entidades en lugar de LINQ to SQL.
La última vez que lo verifiqué, 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 y biológico), por lo que este debate puede prolongarse mientras las partes involucradas se nieguen a definir en sentido literal lo que significa para " Linq para morir ". 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.
Quienes 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 la publicación de Damien Guard ) 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 poco enojados por el nuevo tipo dinámico ).
Aquellos que dicen que "L2S no está muerto" generalmente se refieren al hecho de que L2S no va a ser cortado por completo de .Net (al menos no en el corto plazo). 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 señala Bill Wagner, hay un tiempo y un lugar para ambos.
Llegué tarde a esta discusión, pero quería señalar que ya en 2008, el Gerente de Proyecto de Enlace a SQL (Tim Mallalieu) hizo este anuncio en su blog ,
"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 que indiquen lo contrario.
No, no es. El equipo todavía está trabajando para mejorarlo.
Para toda la gente de "Linq-to-SQL is dead": Scott Guthrie mismo mencionó claramente en TechEd Europe que Linq-to-SQL está COMPLETAMENTE APOYADO en .NET 4, y Damien Guard publicó una publicación de blog sobre qué cambios y mejoras se han realizado hecho para Linq-to-SQL en .NET 4.
Para citar a Mark Twain: "Los informes sobre mi muerte han sido muy exagerados" ...
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.