La historia de mis desventuras

Palabras más, palabras menos sobre desarrollo de software.

¿Linq to Sql ó Entity Framework?

Posted by Jhonny López Ramírez en 8 noviembre 2009

Se me ha preguntado recientemente bajo qué criterios debía tomarse la decisión de usar EF o LINQ2SQL y haré aquí un resumen de los que considero debían tenerse en cuenta:

En primer lugar debo decir que tengo la impresión de que el proyecto Linq to Sql, a pesar de ser una consecuencia esperable en términos de niveles de abstracción, fue desarrollado como un mientras-lanzamos-EF. Eso no hace que haya sido una mala herramienta y, casi que por el contrario, ha opacado en algunos escenarios al mismo EF. Si analizamos un poco el estado del arte del desarrollo web, lenguajes y frameworks ligeros como Ruby on Rails han devenido adicionalmente en ORM’s ligeros y allí tenemos en L2S un claro ejemplo. Así las cosas, L2S está orientado al desarrollo rápido de aplicaciones conectadas a datos en arquitecturas web o de escritorio. Hace sumamente sencillo el acceso a datos en gran parte por la naturaleza misma de Linq y su similitud con el Sql.

Con Entity Framework sucede que está orientado a la construcción de aplicaciones corporativas en las que el nivel de abstracción del lenguaje de los desarrolladores sea un factor clave. Por ejemplo, permite el mapeo de una clase a diferentes tablas así como usar elementos propios de la programación orientada a objetos tales como la herencia y el polimorfismo. Esto no en todos los casos es una ventaja puesto que tiende a hacer más complejas las situaciones que representa y deriva en olvidar los objetos POCO que tan cómodos suelen resultarnos, aunque sobre esto se haya prometido que en la versión 4.0 del framework se permitirá la compatibilidad entre clases sencillas de un modelo de negocios y EF.

Dicho lo anterior, yo usaría estas listas de chequeo para determinar si uso el uno o el otro:

¿Cuándo EF?

  • Cuando se trata de una aplicación que puede estar conectada a fuentes de datos de diferentes proveedores. Sobre esto EF lleva un poco la ventaja puesto que los proveedores de acceso a datos de terceros tardan menos en aparecer e incluso MS ofrece uno para Oracle. L2S está prácticamente destinado a trabajar con SQL Server.
  • Cuando se necesita un lenguaje de abstracción más cercano a la lógica de negocio. El nivel de abstracción de EF así como su capa de Object Services es mucho más amplia y está orientada a no ser simplemente un ORM sino todo un lenguaje conceptual a la hora de desarrollar aplicaciones conectadas a datos.
  • Cuando se estima que la aplicación sea escalable y de largo desarrollo en el tiempo. La lógica que se puede derivar de aplicaciones sobre EF es mucho más flexible por lo que se puede extender y escalar fácilmente a medida que el proyecto de software crece.

¿Cuándo L2S?

  • Cuando se desarrolla una aplicación de nivel medio y pequeño. Resulta muy cómodo cuando se habla de aplicaciones en Asp.net mvc y casi que se asume como el ORM especial para este framework de desarrollo web. Pero prácticamente en cada escenario en el que el desarrollo esté orientado a datos y sea pequeño o mediano L2S, es una excelente solución pues se tiende a escribir menos código que con EF.
  • Cuando se trata de una aplicación que tendrá por back-end un único proveedor de bases de datos. Y ojálá este sea Sql Server. Se han ido desarrollando por terceros proveedores L2S para bases de datos de terceros pero aún se encuentran en fases de desarrollo tempranas.
  • Los niveles de abstracción que se usan en la aplicación están casi destinados a coincidir con la persistencia de datos. Aquí es donde L2S, al ser un ORM en sí, lleva la ventaja sobre EF y donde más podemos notar una solución sencilla a la disparidad entre POO y modelo relacional.

En conclusión se habrá notado que tiendo a recomendar EF cuando se trata de aplicaciones corporativas, robustas, escalables y de un alto rigor en la representación de la lógica de negocio. Y L2S me parece una herramienta ideal cuando se trata de aplicaciones de tamaño pequeño y hasta mediano. Esto no significa que no se puedan invertir los escenarios de uso, no, pero quizás sí significa que de hacerlo se subutilicen o sean insuficientes los recursos de uno y otro. Para el framework 4.0 se esperan mejoras importantes en ambos y será necesario entonces revisar estas consideraciones. Quizás se vuelva una cuestión de gustos, simplemente.

Por ahora considero como un excelente término medio Linq to Entities, aunque EF se baste y se sobre por sí mismo.

Deja un comentario