LINQ to Entities o LINQ to SQL

Muchos desarrolladores se están empezando a preguntar que diferencia hay entre LINQ to Entities y LINQ to SQL (conocida antes como DLinq).

Aquí me gustaría echar algo de luz al mismo tiempo que traer algunas reflexiones que podréis sacar de los enlaces que os indico en esta entrada.

Con ambas (LINQ to SQL y LINQ to Entities) podemos trabajar con datos, con bases de datos y con EDM (Entity Data Model) que es como sabréis una representación lógica del modelos de datos, así que… ¿cuáles son las diferencias más notables entre ellas o cuál es la «más mejor»?.

Grosso modo, LINQ to SQL está disponible desde ya en Visual Studio 2008 (Microsoft .NET Framework 3.5 para más señas), y con él podremos acceder a los esquemas de bases de datos.

LINQ to Entities no está aún disponible en versión RTM, aunque le falta poco, y sí en versión Beta 3 aunque puede ser usada con Visual Studio 2008 RTM. El único aspecto de relevancia, es que ADO.Net Entity Framework forma parte de la próxima versión de ADO.Net (actualmente en versión Beta 3 como indicaba anteriormente).

Para utilizar satisfactoriamente ADO.Net Entity Framework Beta 3 en Visual Studio 2008 RTM (32 bits), deberemos descargarnos primero el Framework correspondiente (1.3 Mb), y posteriormente ADO.Net Entity Framework Tools CTP Diciembre 2007 (7.1 Mb). También se sugiere que descarguemos el XML Editor QFE (650 Kb). Adicionalmente a todo esto, podemos descargar los ejemplos de la Beta 3 en este enlace (29 Mb) y acceder a la documentación de ADO.Net Entity Framework Beta 3.

Pero volviendo nuevamente a la tesitura de LINQ to Entities o LINQ to SQL, debemos indicar que LINQ to SQL es válida solo para SQL Server y posiblemente para poco más (no he tenido tiempo de revisar si han incluido algún cambio de última hora). LINQ to Entities sin embargo, está pensado para trabajar incluso con diferentes sistemas gestores de bases de datos.

LINQ to SQL es una forma muy sencilla y simple de mapear datos. Para muchas aplicaciones es suficiente, sin embargo, en otras aplicaciones nos podemos quedar «cojos» y ahí aparece LINQ to Entities que mapea datos de una forma más compleja pero al mismo tiempo más potente o más apropiada muchas veces para el mundo real.

¿Cuál elegir entonces?.

Seré gallego y diré… depende.

Depende del mapeo de objetos relaciones y su complejidad, de las necesidades que tengamos y de lo que necesitemos resolver.

En estos casos siempre digo lo mismo. Si vas a circular por una carretera secundaria… ¿te merece la pena circular con un Ferrari?. En cambio, si lo que vamos a hacer es circular por autopistas y en contadas ocasiones y las que menos en carreteras secundarias, igual sí nos merece la pena circular con un Ferrari.

Por eso depende. Cada proyecto es diferente. Puede haber similitudes pero todos los proyectos son diferentes los unos de los otros. El desarrollo del Software como ya sabéis no es una fábrica de churros dónde se hacen las cosas sin esfuerzo alguno, así que elijamos LINQ to SQL o LINQ to Entities siempre tendremos que trabajar un poquito.

Lo importante es que Microsoft nos proporciona estas dos posibilidades para trabajar con entidades y con datos y aquí es donde muchos nos empezamos a hacer pajas mentales.

Finalmente, quería traeros una tabla de comparación entre NHibernate, LINQ to SQL y LINQ to Entities. No he podido verificar los datos de esta tabla, pero de ser correcta sería una interesante tabla de comparación entre estas tres formas de trabajar con entidades (no he hablado de NHibernate hasta ahora porque en realidad no venía a colación hablar de ello directamente). También es destacable unas reflexiones de hace meses sobre NHibernate y LINQ to Entities.

Espero que todo esto ayude a entender un poco más la diferencia sobre todo entre LINQ to SQL y LINQ to Entities.