Blog de Eugenio Serrano
Comentando sobre tecnologías Microsoft desde el interior de Cordoba, Argentina.
If Me.Today = Me.Yesterday Then Me.Tomorrow = Nothing ------------------

¿ Chau a LINQ to SQL ?

Tuesday, 16 December 2008 13:16 by Eugenio

Particularmente LINQ, como herramienta en sí, me parece simplemente espectacular. El nivel de abstracción que provee, integrado al lenguaje de programación, es un gran paso hacia adelante en la posibilidad de expresión que uno puede explotar dentro de la tecnología .Net
De la mano de LINQ vinieron LINQ to XML, LINQ to DataSets, LINQ to SQL y LINQ to Entities, dando la posibilidad de crear nuevos LINQ to xxxx debido a su modelo de extensibilidad.
 
Mas allá de si nos gustan o no los ORMs, a mi particularmente no me gustan demasiado, (si todavía no leíste este post de Diego Dagum acerca de los ORM, lo recomiendo), era algo que la comunidad de desarrollo venía pidiendo hace tiempo, y hoy por hoy nos encontramos con 2 tecnologías parecidas. LINQ to SQL y Entity Framework.

LINQ to SQL fue liberado hace mas de 1 año, junto con .Net 3.5 y Visual Studio 2008, y la versión final de Entity Framework fue liberada hace unos meses junto con .Net 3.5 SP1.

Si bien Entity Framework es mucho más completo y extensible, no puede dejar de compararse a uno con otro, y siempre emerge subrepticiamente la siguiente pregunta:
¿Por qué si estuvimos tantos años sin ORMs, ahora como si fuera poco tenemos 2?

Más allá de los objetivos de cada proyecto, no es demasiado difícil darse cuenta que en algún punto ambos colisionan…

Y según parece (era de esperar), la pelea la ganó LINQ to Entities.

A continuación hago una traducción (a la cordobesa) de un pedacito de texto extraido del blog del team de ADO.Net 

¿Está muerto LINQ to SQL?

Continuaremos haciendo algunas mejoras en LINQ to SQL basándonos en el feedback de nuestros clientes. Dicho anuncio hacía referencia a exponer claramente nuestras intenciones y dar aviso que a partir de. NET 4.0, LINQ to Entities será la solución recomendada de acceso a datos para los escenarios de LINQ to Relational

Como se ha mencionado, hemos estado trabajando en esta decisión por varios meses. Cuando finalmente se tomó la decisión, consideramos importante dar a conocer inmediatamente dicha decisión a la comunidad.

Sabíamos que ser abiertos, daría lugar a una gran reaccion por parte de la comunidad, pero es importante ser transparentes acerca de lo que estamos haciendo tan pronto como sea posible…

O sea, como decimos por aqui... Mas claro, echale agua... :)

 

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Related posts

Comments

December 17. 2008 22:19

Bueno, y ¿cómo encaja aquí el Cooperator con su generador de código y ORM tipado, frente a Object Relationl Designer de Visual Studio 2008 y LINQ to Entities?

Vyacheslav Popov

January 22. 2009 04:58

Hola Eugenio, podrías explicar cuales son las razones por las cuales no te gustan los ORM ? Porque la verdad que leí el post de Diegum y a pesar de que es muy largo, no encontré ni una sola razón.

moebius

January 22. 2009 05:58

Hola moebius:

Tampoco es que los odie, solo que hay que tener mucho cuidado, porque pueden traer consecuencias peligrosas...
Smile

Leíste el "primer mandamiento" ?

"Primer Mandamiento: si todavía no te metiste con O/R-M, no te metas entonces"
http://diegumzone.spaces.live.com/blog/cns" rel="nofollow">http://diegumzone.spaces.live.com/blog/cns!1AD5096D63670065!705.entry?wa=wsignin1.0&sa=215035014

Leete este también (es un link de esa nota), principalmente el intercambio de correos al final...
http://diegumzone.spaces.live.com/blog/cns" rel="nofollow">http://diegumzone.spaces.live.com/blog/cns!1AD5096D63670065!367.entry

Saludos,
Eugenio Serrano

Eugenio

January 23. 2009 15:44

Hola Eugenio, gracias por contestar.

Lo que entiendo sería el mensaje del primer mandamiento es que la probabilidad de que vayas a cambiar de base de datos es baja. Pero no veo esto como una razón para no usar ORMs, el hecho de que un ORM te permita cambiar de base de datos fácilmente es sólo una ventaja adicional pero sin duda no la principal.
Después habla de que si no tenés ORM por lo menos podés hacer JOIN, esto no es cierto porque con los ORM podés también hacer JOIN tranquilamente, y esto utilizando los lenguajes de query a nivel de objetos que proveen los ORM, o sea sin necesidad de usar SQL directamente.

También habla de que el grafo de objetos que te traes está asociado a la clase y no al caso de uso, y esto también es falso porque hay ORM's que te permiten hacerlo.

Y un comentario más en general: se habla de rendimiento y performance pero nada de flexibilidad y mantenibilidad.

Con respecto al segundo link, los gridviews y demás controles con binding se pueden usar con colecciones (ICollection) muy fácilmente, por lo cual no veo cual es la gran diferencia.

Pero acá me parece que salta la ficha, porque se habla de data céntrico y procesos y entidades (o sea la lógica separada de los datos), y entonces es totalmente cierto, si estás usando un enfoque estructurado no tiene sentido usar un ORM.

Pero entonces la discusión habría que ponerla en otros términos: estructurado vs orientado a objetos / data céntrico vs centrado en el dominio.

Saludos.

moebius