usando - ¿Está LINQ to SQL Dead or Alive?
manual de linq to sql en español (16)
Justo cuando me hago amigo de LINQ to SQL, parece que MS está sacando la alfombra de debajo.
A partir de mi pequeña investigación, EF es demasiado exagerado para un trabajo simple. Pero después de este anuncio, ¿hay algún punto para seguir utilizando LINQ to SQL?
Más allá del futuro para LINQ to SQL, ¿no envía esto generalmente una mala señal? Dada la velocidad con la que MS está lanzando bits contra la pared, ¿es racional usar alguno de los nuevos bits antes de tiempo? (¡Y eso es amable, apenas es temprano para LINQ a SQL!).
Para mi trabajo 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
(no, StingyJack, LINQ to SQL no usa el marco de entidad)
De todos modos, no me preocuparía. Tim dice 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 (esos somos nosotros) expresarán lo que piensan.
Y, como señala KristoferA, en realidad no pueden ''matar'' a L2S, solo congelarlo. Y L2S, una vez pulido, realmente no requiere mucho desarrollo adicional. Con el proveedor L2S en su lugar, cualquier avance en LINQ debería estar disponible en L2S también. Entonces la elección seguirá siendo nuestra.
1) No pueden "matar" a Linq-to-SQL ya que es parte del framework .net. Lo que pueden hacer es dejar de agregarle características. Eso no impide que los miles de desarrolladores que ya están usando L2S lo amplíen y lo 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 muchas de las golosinas de L2S en EF y pretendiendo que son cosas nuevas de EF. En otras palabras, la segunda versión de L2S acaba de ser EF "reetiquetada".
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 para objetos, Linq para entidades, Linq para XML, Linq-to-anything ) Por lo tanto, el intento del grupo DP de forzar [a las grandes masas de] L2S a adoptar [el menos popular y actualmente defectuoso] Entity Framework no es motivo para no aprender Linq.
También vea este hilo (que es lo que creo que en parte desencadenó la publicación de blog de Tim): http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1
Actualización 1: El número de diciembre de 2008 de la portada de la revista Visual Studio por Roger Jennings es una buena lectura sobre el tema, con algunas comparaciones L2S vs EF: http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583
Actualización 2: Anders Hejlsberg fue citado en Redmond Developer News diciendo que " LINQ to SQL no está muerto. Puedo asegurarle que no está muerto. Nada desaparece. Nunca lo hemos hecho y nunca lo haremos " .
Alguien recuerda VB6? Ya sea que lo aborrezcas o lo ames personalmente, 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 (tipo de, no el IDE).
- Y Microsoft todavía dice que están escuchando a los clientes de VB6 incluso ahora ( en septiembre de 2009 ).
- ¿Pero son felices 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 de código a la tecnología de reemplazo, VB.Net, son expensive .
Así que solo considera esa lección. Para mí, parece que el soporte de LinqToSQL será bastante rencoroso. Están obliged a soportarlo porque está en el marco .NET actual. ¿Pero será en .NET 5, 6, 7 ...? Solo piensa en cuánto te importa (por lo que sé, no te importa para nada).
Es obvio que 2 ORMs son uno a muchos en la caja de herramientas de Microsoft, pero a mí me parece que se ha elegido el marco equivocado por todas las razones equivocadas. El hecho de que el equipo de C # hizo el trabajo que se suponía que el equipo de ADO.NET debía hacer en mucho menos tiempo e hizo el trabajo mucho mejor es difícil de tragar 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 que tiene linq2sql para el marco de la entidad.
Parece que hay demasiada política involucrada y creo que esto va a dañar la reputación de asp.net, ya que no confío en que el marco de Entity nos brinde una experiencia igualmente amigable como Linq2sql. El equipo de ado.net también podría aprender algunas habilidades de comunicación del equipo 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 de MVC se encuentran aquí, ya que la mayoría de sus ejemplos utilizan Linq2Sql.
Hay una ambigüedad para su pregunta que necesita ser resuelta.
LINQ! = LINQ a SQL
Hay un montón de tecnologías y proveedores de LINQ:
- Linq a SQL;
- Linq a las entidades;
- Linq a los objetos;
- Linq a XML;
... y esos son solo los de Microsoft. También hay proveedores que no son MS, incluido NHibernate.
La publicación de blog que ha vinculado solo habla de Linq a SQL.
La principal ventaja de LINQ es que puede aprender y usar una sintaxis de consulta y reutilizarla en múltiples tecnologías.
Ante esto, sugeriría que cualquier falta percibida de futuro para "Linq To SQL" es irrelevante, ya que las habilidades que obtenga al escribir LINQ Queries serán transferibles a otras herramientas en el futuro.
Honestamente, no entiendo en qué parte de ese artículo lees que link2sql está muerto.
En la publicación de blog que has vinculado, dice:
Estamos escuchando a los clientes con respecto a LINQ to SQL y seguiremos evolucionando el producto en base a los comentarios que recibimos de la comunidad también.
Para mí esto se lee como LINQ to SQL se desarrollará y apoyará en el futuro. Me pregunto por qué piensas que está muerto.
La próxima versión de Windows Phone 7, nombre clave Mango, incluye una edición compacta de SQL Server accesible a través de Linq a SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/
No estamos matando a LINQ to SQL. Estamos optimizando para EF, pero LINQ to SQL definitivamente no está siendo eliminado :)
- Scott / Microsoft.
No solo debe aprender Linq (System.Linq.Enumerable y System.Linq.Queryable), necesitará 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 on first parameter)
- 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 forma abreviada)
Lea más here .
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 #).
Lea más here .
Por supuesto, creo que la elección entre LINQ to SQL, LINQ to Entities y LINQ para [insertar 3rd Party ORM] aquí proporciona un ecosistema perfectamente saludable de metodologías de capa de acceso a datos de las que puede elegir un desarrollador de software. Los proveedores de terceros como NHibernate, LLBLGen e incluso Subsonic (no estoy seguro si van a ofrecer proveedores de LINQ) definitivamente harán que la competencia sea mejor y más interesante.
Dicho esto, será totalmente triste para Microsoft abandonar LINQ a SQL, especialmente porque tiene un buen seguimiento, incluso está basado en él.
Scott Guthrie me dijo que no matarían a LINQ to SQL:
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ó al lanzamiento de .NET 3.5 fue porque había una gran duda de que EF vería la luz del día. Ahora que EF1 está fuera, todo sea un v1 muy difícil, ya no había necesidad de L2S.
Supongo que realmente no veo el problema aquí. Del artículo que has vinculado:
Estamos escuchando a los clientes con respecto a LINQ to SQL y seguiremos evolucionando el producto en base a los comentarios que recibimos de la comunidad también.
¿Me estoy perdiendo de algo? ¿Qué da la impresión de que LINQ to SQL está muerto al llegar?
Tal vez no deberías molestarte en aprender Linq a SQL, pero aún quedan las Entidades Linq que conservarán.
Ver también http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx y los comentarios allí
Interesante publicación de blog sobre esto. Y algo de información relacionada en http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx .
La esencia básica parece ser que los comentarios realizados en el http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx que indican que Entity Framework es lo único que obtiene mayor tiempo de desarrollo para Visual Studio 2010 y Dot Net 4.
Mi respuesta es - DUH. Todos hemos sabido esto. Microsoft dijo públicamente en el PDC 2007 que LINQ to SQL era una versión a corto plazo para SQL Server porque no había otra historia LINQ para SQL Server. Solo funciona con SQL Server. No puede escribir un proveedor de LINQ to SQL; no hay un modelo para él. Era una tecnología única, no extensible.
El Entity Framework es la ÚNICA forma en que Microsoft crea un proveedor de LINQ. El Entity Framework ha resultado ser bastante contreversial, pero creo que se debe en parte al hecho de que LINQ to SQL tiene una mejor experiencia de programador en la actualidad. Entity Framework atrapará y superará LINQ to SQL porque es la herramienta ORM / Mapping del futuro de Microsoft.
EDITAR - Acabo de escribir un poco más detallada sobre esto en mi blog
EDIT2 - Proveedor de IQueryable - NO es lo mismo que un proveedor de LINQ a SQL. Puede escribir su propio proveedor de IQueryable para lo que desee. No obtiene soporte de diseñador o generación de modelos. No existe un modelo de diseñador de GUI que conozca para vincularlo a la generación de modelos de LINQ a SQL.