martes, 27 de mayo de 2008

Entity Framework SP1 (o como no debe usted implementarse su propio O.R.M. a estas alturas...)

Con el reciente lanzamiento de la Beta del Visual Studio 2008 SP1 por parte de Microsoft me he decidido a investigar la nueva versión del Entity Framework que en el se incluye. Tengo que decir que aunque la cosa todavía esta un poco verde promete.

Se caia de maduro que Microsoft necesitaba cubrir un nicho en la que las soluciones de terceros (Hibernate, Neo, Codus...) se le habian colado en su bonito .NET Framework: Los Object Rational Mapping (ORM) y los servicios de consultas contra dichos objetos.

Microsoft ha realizado intentos, timidos pasos hacia lo que hoy es (o mejor dicho mañana será) el Entity Framework. Se probó con el DataSet, que prometia ser la revolución y se quedo por el camino, muy mal acompañado del XSD para definir modelos. Las especificaciones completas de XSD además de ser infumables, se olvidan por completo de hablar de servicios como la persistencia. Así que no es el lenguaje optimo para hablar de entidades que queremos trabajen con el ORM.

De hecho, existe una nueva especificación para definir los modelos conceptuales (CSDL), de almacenamiento (SSDL) y mapeo el E.D.M.(Entity Data Model). Dichas especificaciones cubren ambos mundos de manera muy natural (puesto que para eso ha sido creado, dicho sea de paso)

Disponer de un ORM (entre otras funcionalidades) estandar y mantenido por Microsoft es un tema a tener muy en cuenta. Yo por mi cuenta, me cree hace un par de años una implementación propia de un ORM común para mis proyectos. Pero no solo yo, es que casi todos los colegas con cierta carga de proyectos se han ido haciendo las suyas propias formando una torre de Babel de lo más poco práctica.

Y el problema no solo es hacerlo sino mantenerlo (y más rápido que Microsoft) desviando esfuerzo de la implementación de sus propias aplicaciones. Por eso es tan interesante el Entity Framework.

Por supuesto, existe la guinda del pastel en forma de LINQ to Entities que es una implementación del proveedor de LINQ para trabajar contra objetos de tipo Entidad (Definidos en el E.D.M.) e incluso una implementación de SQL llamada eSQL(subconjunto muy limitado (sin instrucciones DML para la release 1)) para atacar directamente al nuevo cliente EntityClientProvider que se coloca sobre los proveedores de todas la vida, abstrayendo de sus particularidades.

En este aspecto coincidimos todos los que "parimos" cualquier implementación mejor o peor (que de todo hay no se vayan a crerer) de ORM, en cuanto madure un poco, al trastero con las soluciones propias y a trabajar con el Entity Framework.

Como ven hay muchas cosas interesantes pero ya las iremos viendo poco a poco.

Un saludo.

No hay comentarios: