El entity framework es una nueva forma de acceder datos utilizando .NET. En este post vamos a conversar acerca del rol del EF ( Entity Framework ) dentro de una arquitectura n-layer.
¿Qué es el Entity Framework?
Lo primero que tenemos que hacer para entender el rol que juega en EF en una arquitectura n-layer, es entender que es el EF. De acuerdo a la definición del msdn, el EF es un conjunto de tecnologías que brindan soporte para desarrollar aplicaciones orientadas a datos. Esta definición agrega además que los arquitectos y desarrolladores tiene que enfocarse en dos objetivos diferentes: modelar entidades y relaciones, y además deben de trabajar con motores de datos para guardar y obtener datos, por lo que hace más complejo el proceso de diseño de aplicaicones. En otras palabras, sin el EF se deben de crear dos modelos, uno para los objetos y otro para las base de datos y entender ambos. Esto se da por que la forma de acceder y administrar los datos desde un modelo de objetos es diferente respecto a la forma en que se hace desde una base de datos. Este y otros muchos problemas vienen a ser solucionados por el EF.
El EF es un ORM que permite manejar la traducción de datos entre dos modelos que son muy diferentes, el modelo de objetos de una aplicación y el modelo de la base de datos. Para ver estas diferencias vamos a ver un ejemplo muy simple y muy utilizado en el día a día de nosotros los desarrolladores de software: un maestro detalle de una factura. Al modelar un maestro detalle en un diagrama de base de datos, vamos a tener inicialmente la tabla maestro con toda la información relacionada con el encabezado de la factura, por ejemplo el nombre del cliente, la fecha de la venta, etc. Seguidamente en el detalle debe de ir todo lo relacionado con el detalle de una factura, por ejemplo el id del producto vendido, el precio, la cantidad, y el más importante respecto al punto que tratamos: el ID del encabezado de la factura al que pertenece el detalle. Por el contrario, en un diagrama de clases el objeto que representa el detalle no conoce quién es su padre, ya que el objeto hijo es contenido dentro del padre, ya sea a través de una colección de objetos, un arreglo, o cualquier otra estructura disponible en el lenguaje.
Un ORM lo que hace es llevar a cabo esta transformación de datos que normalmente nosotros hacemos a mano cuando interactuamos con la base de datos; es decir, todo lo que normalmente hacíamos desde los métodos de la capa de acceso a datos, ya sea para obtener datos o para llevar a cabo operaciones de actualización, inserción y borrado. Los ORM además abstraen la funcionalidad requerida para interactuar con un repositorio de datos, por ejemplo el abrir y cerrar la conexión, el “lazy loading” de datos, el manejo de las relaciones, etc. Algunas de estas tareas igualmente las llevamos a cabo en la capa de acceso a datos y la forma tradicional de abstraer el manejo de las conexiones y la interacción con el repositorio de datos es utilizando el “data access application block”.
Rol del EF en una Arquitectura n-layer
Como podemos ver, el EF viene a jugar el rol que tradicionalmente ocupaba nuestra capa de acceso a datos en la arquitectura tradicional n-layer. Es decir, la librería que normalmente creabamos para acceder y abstraer el acceso al o a los repositorios de datos, ya no es necesaria dado que el EF nos da toda la funcionalidad requerida para poder interactuar con el o los repositorios de datos. Claramente dicho, el EF reemplaza la capa de acceso a datos en una arquitectura n-layer.
En post siguientes vamos a explorar más detalladamente la funcionalidad del entity framework.
3 comentarios:
Gracias por el post. Me ayudó mucho a aclarar el funcionamiento del Entity Framework. Ahora bien, me gustaría saber cuáles son sus desventajas? He conocido colegas que me recomiendan elaborar mi DAL con el uso de archivos xml que me den la portabilidad que ofrece EF pero con mayor control del código de la aplicación. Qué opinas?
Gracias de antemano por tu atención. Saludos.
Que tal Alfonso? Mira, yo creo que el EF es una forma de agilizar el desarrollo de la capa de acceso a datos y la capa de entidades de Negocios. En realidad yo antes del EF ( no era un ferviente creyente de los ORM ) utilizaba el Data Access Application Block. Además para mi capa de entidades utilizaba POCO - Plain Old CRL Objects - por una cuestión de rendimiento versus Datasets.
El EF además tiene la ventaja que se puede extender para agregar más funcionalidad - algo que voy a poner en un post en las próximas semanas. Tengo varios post respecto al EF en una arquitectura n layer : http://icomparable.blogspot.com/search/label/Entity%20Framework que te pueden ayudar a entender más acerca de como implementar el EF en una aplicación n capas. Respecto a la portabilidad, el EF es portable si se utiliza como se muestra en los post, dado que la capa de acceso a datos, el EF - es generada y simplemente se utiliza como librería de nombres y tipos desde la clase de lógica de negocios.
Saludos y gracias por escribir
Con el EF ya no es necesario crear en la capa de negocios los objetos del modelo???lo creo el EF automaticamente en DAL?????podría darme una pequeña explicación de cómo se esctructurarían las aplicaciones con el EF??
Publicar un comentario