¿LINQ to SQL está vivo o muerto?

Justo cuando me hago amigo de LINQ to SQL, parece que MS está tirando la alfombra debajo de él.

http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx

De mi pequeña investigación, EF es demasiado para el trabajo simple. Pero después de este anuncio, ¿tiene sentido seguir usando LINQ to SQL?

Más allá del futuro de LINQ to SQL, ¿esto no suele enviar una mala señal? Dada la velocidad con la que MS lanza bits contra la pared, ¿es racional usar alguno de los nuevos bits antes? (y eso es amable, ¡no es pronto para LINQ to SQL!).

Para mi trabajo de LINQ to SQL, creo que me dirijo a SubSonic.

Actualización: Un par de nuevas opiniones:

http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx

1) No pueden "matar" Linq-to-SQL, ya que ya es parte del marco .net. Lo que pueden hacer es dejar de agregarle funciones. Eso no impide que los miles de desarrolladores que ya están usando L2S lo amplíen y mejoren. Algunas áreas centrales son difíciles de tocar, pero ya son sólidas y las características del diseñador que faltan se pueden atornillar fácilmente .

2) Una de las sesiones de PDC EF muestra que han aprendido un par de lecciones del fiasco de EFv1 y ahora están copiando y pegando muchos de los beneficios de L2S en EF y fingiendo que son cosas nuevas de EF. En otras palabras, la versión dos de L2S acaba de ser "reetiquetada" EF.

3) LINQ como tal (Language Integrated Query) es lo mejor desde el helado en rodajas y se puede usar con muchas otras cosas además de L2S (Linq a objetos, Linq a entidades, Linq a XML, Linq-a-cualquier cosa ). Así que el intento del grupo de DP de forzar [a las vastas masas de] adoptantes de L2S a [el menos popular y actualmente defectuoso] Entity Framework no es razón para no aprender Linq.

También vea este hilo (que es lo que creo que desencadenó en parte la publicación del blog de Tim): http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1

Actualización 1: la edición de diciembre de 2008 de la historia de portada de Visual Studio Magazine de Roger Jennings es una buena lectura sobre el tema, con algunas comparaciones entre L2S y EF: http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583

Actualización 2: Anders Hejlsberg fue citado en Redmond Developer News diciendo " LINQ to SQL no está muerto. Puedo asegurarles que no está muerto. Nada desaparece nunca. Nunca hemos hecho eso y nunca lo haremos " .

http://reddevnews.com/blogs/weblog.aspx?blog=3016

Hay una ambigüedad en su pregunta que debe resolverse.

LINQ! = LINQ to SQL

Hay un montón de tecnologías y proveedores de LINQ:

• Linq a SQL;
• Linq a entidades;
• Linq a Objetos;
• Linq a XML;

... y esos son solo los de Microsoft. También hay proveedores que no pertenecen a la EM, incluido NHibernate.

La publicación del blog que vinculó solo habla de Linq to SQL.

La ventaja clave de LINQ es que puede aprender y usar una sintaxis de consulta y reutilizarla en múltiples tecnologías.

Dado esto, sugeriría que cualquier percepción de falta de futuro para "Linq To SQL" es irrelevante, ya que las habilidades que gane al escribir consultas LINQ serán transferibles a otras herramientas en el futuro.

No estamos matando LINQ to SQL. Estamos optimizando para EF, pero LINQ to SQL definitivamente no se eliminará :)

- Scott / Microsoft.

No solo debe aprender Linq (System.Linq.Enumerable y System.Linq.Queryable), también deberá aprender las mejoras del lenguaje de programación para su lenguaje .net.

En C # 3.0, estos incluyen:

• Métodos de extensión (métodos estáticos con la palabra clave this en el primer parámetro)
• Tipos inferidos del compilador (var)
• Sintaxis Lambda (que genera un método anónimo o una expresión según el contexto)
• Inicializadores
• Implementación predeterminada de la propiedad (una abreviatura)

Leer más aquí .

En VB 9.0 hay algo de magia XML en línea y muchas otras cosas (muchas son similares a la lista anterior para C #).

Leer más aquí .

Honestamente, no entiendo en qué parte de ese artículo leyó que link2sql está muerto.

En la publicación del blog a la que vinculó dice:

Estamos escuchando a los clientes con respecto a LINQ to SQL y también continuaremos evolucionando el producto en función de los comentarios que recibamos de la comunidad.

Para mí, esto se lee como LINQ to SQL se desarrollará y apoyará en el futuro. Me pregunto por qué piensas que está muerto.

Por supuesto, creo que la elección entre LINQ to SQL, LINQ to Entities y LINQ to [insertar ORM de terceros] aquí proporciona un ecosistema perfectamente sano de metodologías de capa de acceso a datos entre las que un desarrollador de software puede elegir. Los proveedores externos como NHibernate, LLBLGen e incluso Subsonic (no estoy seguro de si van a ofrecer proveedores LINQ) definitivamente harán que la competencia sea mejor y más interesante.

Dicho esto, será totalmente triste para Microsoft abandonar LINQ to SQL, especialmente porque tiene muchos seguidores, incluso StackOverflow se basa en él.

Publicación de blog interesante al respecto. Y algo de información relacionada sobre las publicaciones de Stackoverflow .

La esencia básica parecen ser los comentarios hechos en el blog ado.net que afirman que Entity Framework es lo único que obtiene un mayor tiempo de desarrollo para Visual Studio 2010 y Dot Net 4.

Mi respuesta es - DUH. Todos lo hemos sabido. Microsoft dijo públicamente en el PDC 2007 que LINQ to SQL era un lanzamiento a corto plazo para SQL Server porque no había otra historia de LINQ para SQL Server. Solo funciona con SQL Server. No puede escribir un proveedor LINQ to SQL, no hay un modelo para ello. Era una tecnología única, no extensible.

Entity Framework es la ÚNICA forma que tiene Microsoft de crear un proveedor LINQ. Entity Framework ha resultado ser bastante polémico, pero creo que eso se debe en parte al hecho de que LINQ to SQL tiene una mejor experiencia de programador en la actualidad. Entity Framework capturará y superará a LINQ to SQL porque es la herramienta ORM / Mapping del futuro de Microsoft.

EDITAR - Acabo de escribir un poco más detallado sobre esto en mi blog

EDIT2 - Proveedor IQueryable - NO es lo mismo que un proveedor LINQ to SQL. Puede escribir su propio proveedor IQueryable para lo que quiera. No obtienes soporte de diseñador ni generación de modelos. No hay ningún modelo de diseñador de interfaz gráfica de usuario que conozca para vincularlo con la generación de modelos LINQ to SQL.

Creo que realmente no veo el problema aquí. Del artículo que ha vinculado:

Estamos escuchando a los clientes con respecto a LINQ to SQL y también continuaremos evolucionando el producto en función de los comentarios que recibamos de la comunidad.

¿Me estoy perdiendo de algo? ¿Qué da la impresión de que LINQ to SQL está muerto al llegar?

Scott Guthrie me dijo que no matarían LINQ to SQL:

Publicar en LINQDev.com

¿Alguien recuerda VB6? Ya sea que lo odie personalmente o lo ame, Microsoft vendió millones de copias y las empresas gastaron millones de dólares escribiendo millones de líneas de VB6. ¿Qué pasó después?

• Bueno, Microsoft todavía es compatible con VB6 (más o menos, no con el IDE).
• Y Microsoft todavía dice que está escuchando a los clientes de VB6 incluso ahora ( en septiembre de 2009 ).
• ¿Pero están contentos los clientes de VB6? No desde 2002 , 4 años después del lanzamiento de VB6.
• Por qué no? Las rutas de actualización para su inversión en código a la tecnología de reemplazo, VB.Net, son costosas .

Así que considere esa lección. Para mí, parece que el soporte de LinqToSQL será bastante de mala gana. Están obligados a admitirlo porque está en el marco .NET actual. Pero, ¿estará en .NET 5, 6, 7 ...? Solo piensa en lo mucho que te importa (por lo que sé, no te importa en absoluto).

Tal vez no debería molestarse en aprender Linq a SQL, pero todavía están las Entities Linq que conservarán.

Consulte también http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx y los comentarios allí

Es obvio que 2 ORM es uno para muchos en la caja de herramientas de Microsoft, pero a mí me parece que se ha elegido el marco incorrecto por las razones equivocadas. El hecho de que el equipo de C # hizo el trabajo que se suponía que debía hacer el equipo de ADO.NET en mucho menos tiempo y lo hizo de una manera mejor es difícil de aceptar para el equipo de ado.net. No es que conozca el funcionamiento interno de los 2 marcos, pero creo que sería mucho más rápido actualizar las deficiencias de linq2sql en el marco de la entidad.

Parece que hay demasiada política involucrada y creo que esto realmente va a dañar la reputación de asp.net, ya que no confío en que Entity framework nos brindará una experiencia igualmente amigable como Linq2sql. El equipo de ado.net también podría aprender algunas habilidades de comunicación del equipo de asp.net mvc ya que las aclaraciones sobre el problema son, en el mejor de los casos, vagas.

Sería divertido aprender lo que Scott Gu y su equipo MVC están aquí, ya que la mayoría de sus ejemplos utilizan Linq2Sql.

Siempre fue un poco extraño que con Linq 2 Sql y Entity Framework hubiera grandes áreas de superposición. Creo que la única razón por la que L2S solo llegó a la versión .NET 3.5 fue porque existía una gran duda de que EF alguna vez vería la luz del día. Ahora que EF1 está disponible, ya sea una v1 muy tosca, ya no había necesidad de L2S.

(no, StingyJack, LINQ to SQL no usa el marco de la entidad)

De todos modos, no me preocuparía. Tim afirma que están escuchando a los clientes con respecto a LINQ to SQL. A juzgar por el entusiasmo que he visto por L2S, los clientes (somos nosotros) dirán lo que piensan.

Y, como señala KristoferA, en realidad no pueden "matar" L2S, solo congelarlo. Y L2S, una vez pulido, no requiere mucho más desarrollo. Con el proveedor L2S en su lugar, cualquier avance en LINQ debería estar disponible también en L2S. Así que la elección seguirá siendo nuestra.

La próxima versión de Windows Phone 7, nombre en clave Mango, incluye una edición compacta de SQL Server accesible a través de Linq para SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/