albloguera

Hace más o menos un año, en mi anterior  @ empresa,  cuando me encontraba en una situación de “Entre Proyectos”, se me asignó la tarea de investigar el Framework NHibernate y desarrollar  un proyecto Interno, para demostrar la valía del Framework .

La verdad es que ya había tenido un primer contacto con el padre de NHibernate, es decir Hibernate, por lo que el proyecto me resulto interesante. Como idea, prometía. El resultado no me resultó del todo satisfactorio. No vi el framework totalmente integrado con .Net. Desde mi punto de vista el uso  de NHibernate para el desarrollo de un proyecto serio en .Net no aporta ventajas frente al uso de la capa DAO tradicional.

Ahora con la aparición de ADO.NET Entity Framework  me ha vuelto a picar la curiosidad.

¿Qué es ADO.NET Entity Framework?

Para definir al Entity Framework me voy a basar en una definición del modelo entidad-relacion. En el modelo entidad-relacion tal y como lo conocemos, tenemos que implementar un conjunto de clases que definen el modelo conceptual de la base de datos y tenemos que definir la capa de acceso a datos, de tal manera que sea esta la encargada de acceder a la base de datos y mapear los datos en las clases creadas para tal efecto.

Manteniendo esta definición en mente, definimos el Entity Framework como un modelo entidad-relación ejecutable, (misma definición para NHibernate).  El Entity Framework nos permite trabajar con los objetos definidos a partir del modelo de datos sin tener que preocuparnos de la capa de acceso a datos ya que él se encarga automáticamente de su persistencia.

Formas de Acceder al modelo de datos.

Antes de enunciar las distintas formas de acceder al modelo de datos, tenemos que comentar que las tres hacen uso de un nuevo proveedor de datos definido en ADO.NET. Este proveedor esta definido de forma similar a los otros ya disponibles, del modo que tenemos una clase  EntityConection para definir el origen de datos y una clase  EntityCommand sobre el que definiremos la consulta a ejecutar.

Si nos fijamos el resultado es un objeto DbDataReader. En esta consulta estamos operando sobre un Entity Data Model  (EDM) “España”, y una Entity (EntitySet) “Ciudades”.

A partir del nuevo proveedor de datos tenemos tres posibilidades para acceder a nuestro modelo de datos:
 

EntitySQL, es un nuevo lenguaje de consultas como hemos visto en el ejemplo anterior (idea parecida al HSQL de Nhibernate).

 Servicios del Objeto: A diferencia del anterior,  de esta forma conseguimos que el resultado de nuestra consulta sea un conjunto de objetos de nuestro modelo, sobre el que podremos realizar una navegación de acuerdo al EDM definido (“Ciudad” -> “Barrio”). Además conseguiremos persistencia de los datos, ya que los cambios que hagamos sobre los objetos pueden ser mantenidos en la base datos automáticamente.

LINQ to Entities: Es otra forma de obtener objetos del modelo, pero usando la sintaxis de LINQ en vez de EntitySQL.

Por último, veamos los ficheros que se van a  generar al definir  un EDM con Visual Studio:

• CSDL: define las entidades y sus relaciones tal  y como la capa de negocio  las conoce.

• SSDL: Define el esquema de tablas de la base de datos en un modelo lógico mediante XML

• MSL: Fichero intermedio que sirve para mapear ambos esquemas.

El asistente además de generar estos ficheros  de definición de nuestra base de datos, también crea un fichero por cada una de las tablas / clases que identifica.

Para terminar esta primera aproximación con el Entity Framework, y como el artículo lo comencé con una opinión del framework NHibernate, voy a plantear una serie de artículos en el que voy a desarrollar un pequeño proyecto, haciendo uso del Entity Framework, con nombre en clave “Mapa de conocimientos de Vicious Team”, de tal manera que pueda cofrontar una opinión mas certera de los dos framework aquí mencionados.

Si queremos saber mas sobre ADO.NET Entity Framework.

De especial interés este otro articulo.