3.15.2009

Como agregar un binding TCP de forma programada a un sitio web en IIS 7.0

La información del binding en un sitio web es indispensable para indicar cuales protocolos pueden ser utilizados para comunicarse con el sitio Web. En el contexto de WCF esto significa, que tipos de protocolos vamos a poder utilizar para consumir los servicios desarrollados en WCF y hosteados en IIS 7.0 y WAS.

En días pasados conversando con algunas personas que usan IIS 7.0 para hostear servicios en WAS utilizando el protocolo TCP, me preguntaron como agregar el binding de TCP a un sitio web utilizando el API de IIS 7.0 y C#. La consulta me pareció muy útil por que permite crear instaladores que hagan deploy de los servicios de forma transparente, incluso creando sus sitios webs a la hora de la instalación y agregando el binding deseado con este instalador. Aquí esta la solución a esta consulta.

Primeramente, vamos ver que es lo que necesitamos para tener el protocolo TCP habilitado en el sitio web. Para esto, en el archvio applicationHost.config  existe la sección bindings la cual existe por sitio web definido y tiene el siguiente formato:

<bindings>
    <binding protocol="http" bindingInformation="*:80:" />
    <binding protocol="net.tcp" bindingInformation="808:*" />
    <binding protocol="net.pipe" bindingInformation="*" />
    <binding protocol="net.msmq" bindingInformation="localhost" />
    <binding protocol="msmq.formatname" bindingInformation="localhost" />
</bindings>

Como podemos ver en el elemento XML anterior, existe una etiqueta binding para cada protocolo que queremos soportar en el sitio web. Además, cada elemento tiene dos atributos: protocol y bindginInformation. El protocolo define el protocolo que se utiliza para comunicarse con el sitio web, y el bindingInformation contiene la dirección IP, el número del puerto y opcionalmente el host header para el sitio web.

Para poder agregar TCP al sitio web deseado debemos primeramente buscar el elemento que contiene los sitios web en el archivo de configuración del servidor, seguidamente buscamos el sitio web deseado, y procedemos a agregarle el binding. El código para esta operación es el siguiente:

public static void AgregarBindiingASitioWeb( string nombreSitioWeb, string protocolo, string bindingInformation )
{
using (ServerManager server = new ServerManager( ))
{
Configuration hostConfiguration = server.GetApplicationHostConfiguration( );
ConfigurationSection sitesSection = hostConfiguration.GetSection("system.applicationHost/sites"); //utilizamos XPath para obtener el elemento
ConfigurationElementCollection sitesCollection = sitesSection.GetCollection( ); //Obtenemos todos los sitios web en el archivo
//Buscamos el sitio web deseado
ConfigurationElement siteElement = FindElement(sitesCollection, "site", "name", @nombreSitioWeb);
//Si no existe, lanzamos una excepción y abortamos el método.
if (siteElement == null) throw new InvalidOperationException("Sitio no encontrado!");
//Obtenemos la configuración del binding del sitio web
ConfigurationElementCollection bindingsCollection = siteElement.GetCollection("bindings");
//Creamos un elemento de binding para el sitio y le establecemos los valores deseados
ConfigurationElement bindingElement = bindingsCollection.CreateElement("binding");
bindingElement["protocol"] = @protocolo;
bindingElement["bindingInformation"] = @bindingInformation;
//Agregamos el binding a la colección de bindings del sitio web
bindingsCollection.Add(bindingElement);
//Guardamos los cambios en el archivo applicationHost.config
server.CommitChanges( );
}
}


private static ConfigurationElement FindElement( ConfigurationElementCollection collection, string elementTagName, params string[] keyValues )
{
//Iteramos sobre la coleccion de elementos para buscar la etiqueta site que tenga en el atributo
//name el valor pasado por parámetro
foreach (ConfigurationElement element in collection)
{
//Si el elemento encontrado es el sitio
if (String.Equals(element.ElementTagName, elementTagName, StringComparison.OrdinalIgnoreCase))
{
bool matches = true;
//Entonces buscamos el atributo deseado
for (int i = 0; i < keyValues.Length; i += 2)
{
object o = element.GetAttributeValue(keyValues[i]);
string value = null;
if (o != null)
{
value = o.ToString( );
}
if (!String.Equals(value, keyValues[i + 1], StringComparison.OrdinalIgnoreCase))
{
matches = false;
break;
}
}
if (matches)
{
return element;
}
}
}
return null;
}


El código para llamar al método de crear binding es:



AgregarBindiingASitioWeb("MiNuevositioWeb", "net.tcp", "808:*");



Antes de ejecutar el código anterior, el elemento Site de MiNuevoSitioWeb lucía así:



image Después de ejecutar el código anterior el resultado es:



imageComo podemos ver en la figura anterior, el binding para TCP se agregó al elemento del sitio web solicitado.

3.08.2009

Eclipse y Silverlight

Normalmente, cuando pensamos en silverlight pensamos en .NET. Resulta ser, que una empresa francesa en conjunto con Microsoft, desarrolló un plug in para Eclipse que permite desarrollar aplicación silverlight utilizando Java.

El articulo que nos muestra que contiene este plug in se puede ver en el sitio de la empresa que desarrolla el plug in. Los pasos para utilizar este plug in con eclipse se pueden ver en el blog de somasegar en el msdn.

También es interesante destacar un producto llamado eFace de esta empresa, que permite desarrollar UI’s utilizando XAML en Java. El link de este producto – el cual tiene una versión gratuita – se puede ver acá.

3.02.2009

Utilizando el API de IIS 7 para crear Web Sites Aplicaciones, Directorios Virtuales y para explorar mi servidor Web desde .NET

En días pasados tuve la necesidad de crear una aplicación que me permitiera llevar a cabo acciones sobre el IIS para poder realizar acciones tales como crear un Sitio Web desde una aplicación desarrollada en C#. Es por eso, que en este post decidí escribir un poco acerca de como llevar a cabo estas tareas utilizando VS 2008, C#, IIS 7.0 y el API manejado para acceder las funcionalidades del IIS – al menos algunas.

El API de IIS 7.0 es una librería localizada en el directorio C:\Windows\System32\inetsrv\ – Asumiendo que la instalación de Windows esta en el disco C – y es un assemblie que se llama Microsoft.Web.Administration.dll. Esta vez, vamos a hacer una aplicación de consola que nos permita realizar un par de tareas contra el IIS.

Una vez creada la aplicación de consola procedemos a agregar una referencia al componente que nos va a exponer la funcionalidad disponible del IIS, es decir, el Microsoft.Web.Administration.dll. La siguiente figura nos muestra la referencia agregada al proyecto de ejemplo.

image

Una vez agregada esta referencia, procedemos agregar la referencia a la libreria para poder utilizarla en nuestra aplicación tal y como se muestra en el siguiente código:

using System;
using Microsoft.Web.Administration;



Luego a agregar funcionalidad a nuestra aplicacion para acceder al IIS 7.0. Lo primero que vamos a hacer es desplegar la lista de sitios web que han sido creados en el IIS con el que vamos a interactuar, en este caso, el servidor Web local. El código para llevar a cabo este procedimiento es el siguiente.



static void Main( string[] args )
{
ListarSitiosWeb( );
}

private static void ListarSitiosWeb( )
{
using (ServerManager server = new ServerManager( ))
{
foreach (Site site in server.Sites)
{
Console.WriteLine("Sitio Web:{0}", site.Name);
}
}
}



Como se ve en el código anterior, lo primero que debemos hacer es crear una instancia de la clase ServerManager, la cual representa el servidor Web instalado en mi máquina. Seguidamente, para imprimir el nombre de los sitios web creados en el servidor Web simplemente recorro la colección de Sites presente en mi servidor web. La salida de este código es:



image





Para crear un Sitio web desde mi aplicación en .NET utilizo el siguiente código.



/// <summary>
///
Permite crear un web site utilizando el API de IIS 7
/// </summary>
/// <param name="siteName">
El nombre del sitio web</param>
public static void CreateSite( string siteName )
{
try
{
using (ServerManager mgr = new ServerManager( ))
{
Site newSite = mgr.Sites.CreateElement( );
newSite.Id = DateTime.Now.Second;
newSite.SetAttributeValue("name", siteName);
mgr.Sites.Add(newSite);
mgr.CommitChanges( );
}
}
catch (Exception ex)
{
Console.WriteLine("Error: {0}", ex.ToString( ));
}
}


Este código permite crear un sitio web con el nombre que viene por parámetro – siteName – y con un Id obtenido del segundo en que fue creado el sitio web. Seguidamente agregamos el sitio a la colección de sitios del IIS, y le damos CommitChanges para refrescar el sitio web.



Otra funcionalidad con la que tenemos que trabajar cuando creamos es crear una Aplicación. Una aplicación en IIS es un agrupamiento de contenido en un sitio Web. Estas aplicaciones tienen una ruta física para el contenido y propiedades que son específicas al contenido indicado. Para crear una aplicación en el sitio web antes creado agregamos el siguiente código.



private static void AgregarAplicacion( string sitioWeb )
{
try
{
using (ServerManager server = new ServerManager( ))
{
server.Sites[sitioWeb].Applications.Add("/", @"C:\Proyectos\MiSitio");
server.CommitChanges( );
}
}
catch (Exception ex)
{
Console.WriteLine("Error creando aplicación {0}: {1}", sitioWeb, ex.ToString( ));
}
}



En este código, el método Add de la colección de aplicaciones del sitio web recibe dos parámetros, el primero es la ruta dentro del servidor web donde se va a administrar el contenido – en este caso en el directorio raíz del sitio web - , y el segundo parámetro que indica la ubicación física del contenido.



Por último, le vamos a agregar un directorio virtual a la aplicación que acabamos de crear.



public static void AgregarDirectorioVirtual( string nombreSitioWeb, string aplicacion )
{
using (ServerManager server = new ServerManager( ))
{
Site sitioWeb = server.Sites[nombreSitioWeb];
Application app = sitioWeb.Applications[aplicacion];
app.VirtualDirectories.Add("/ASPX", @"C:\Proyectos\MiSitio");
server.CommitChanges( );
}
}


Este código agregar un directorio virtual llamado ASPX, en la ruta física C:\Proyectos\MiSitio, por lo tanto va a estar mapeado a esta dirección física.

2.27.2009

¿Qué es WCF? – Parte 4. Arquitectura de WCF

Como vimos en los posts anteriores, WCF nos facilita la manera de crear servicios para poder consumirlos de forma sencilla a partir de la generación de un proxy que actúa como interceptor de la llamada y nos abstrae de toda la plomería necesaria para conectarnos con el provedor del servicio y obtener el resultado deseado. En este post vamos a hablar acerca de la arquitectura de WCF.

Todas las características de WCF, entre ellas confiabilidad, administración de la concurrencia, seguridad, y activación de instancias, dependen de la arquitectura de WCF, conocida como arquitectura basada en intercepción. El hecho de que un cliente interactúe con un proxy, significa que WCF siempre esta presente entre el servicio y el cliente, interceptando la llamada y llevando a cabo pre procesamiento y post procesamiento.

Esta “intercepción” inicia cuando el proxy serializa la llamada a un stack frame para un mensaje y envía el mensaje hacia abajo en la cadena de canales. El canal es simplemente un interceptor que tiene como propósito llevar a cabo tareas específicas. Este concepto de canal es algo muy similar al manejo de “pipes” utilizado por Biztalk Server para procesar mensajes.

Cada canal del lado del cliente hace un pre procesamiento del mensaje. La estructura exacta y la composición de la cadena depende en su mayoría del tipo de binding que se este utilizando. Por ejemplo, un canal puede estar encargado de la codificación del mensaje (MTOM, texto, etc.), otro de pasar el contexto de seguridad, otro de propagar las transacciones, otro por manejar la confiabilidad de la sesión, otro para encriptar el mensaje y así sucesivamente. El último canal del lado del cliente es el canal de transporte el cual envia el mensaje a través del transporte configurado en el host.

Del lado del servidor, el mensaje “sube” otra vez por la cadena de canales pero en sentido inverso al channel stack del cliente. Es decir, el primer canal en participar en el server es el canal de transporte, el cual recibe el mensaje.  Los canales subsecuentes llevan a cabo las tareas inversas realizadas en el cliente; por ejemplo, si en el cliente se encripto el mensaje, en el server se desencripta el mensaje. Igualmente, en esta ruta del mensaje se activa la instancia del servicio requerida para consumir el servicio. El último canal en el servidor pasa el mensaje a un elemento conocido como el dispatcher. El dispatcher es el elemento que administra la ejecución de servicio. El dispatcher convierte el mensaje en un stack frame ( lo deserializa. y llama la instancia del servicio creada para completar el llamado). En la siguiente figura se puede ver este proceso.

image Como se puede ver, el servicio no sabe que fue llamado por un cliente externo, y el cliente no sabe que se esta comunicando con un cliente externo. Ambos, ven los componentes localmente para comunicarse – el cliente en el proxy y el servicio en el dispatcher. Este concepto de intercepción en ambos lados, cliente y servidor, garantiza que ambos obtiene el ambiente de ejecución que se requiere para operar correctamente.

Por último, en el proceso de respuesta, la instancia del servicio ejecuta la llamada y retorna el control al dispatcher, el cual a su vez convierte los valores retornados y la información del error – si existe – en el mensaje de regreso. El proceso se invierte siendo el dispatcher el que inicia la cadena del llamado, y el proxy el último en contestarle al cliente.

Para concluir podemos destacar que esta arquitectura nos permite extensibilidad en el modelo, ya que podríamos crear canales personalizados para interacciones propietarias o propias de un negocio o plataforma en específico.

2.25.2009

Nuevo Look de Visual Studio 2010

Como muchos de ustedes saben, en el 2010 saldrá la nueva versión de VS, la versión 4.0. Mucho se ha especulado acerca de esta herramienta, ya que el UI de la herramienta ha sido reescrito utilizando WPF. Leyendo blogs en msdn, me encontré las primeras fotos del look de VS 2010 escrito en WPF. Aquí les dejo el link para que lo puedan ver.

http://blogs.msdn.com/jasonz/archive/2009/02/20/a-new-look-for-visual-studio-2010.aspx

2.22.2009

¿Qué es WCF? – Parte 3

En el post anterior finalizamos hablando de proxies y metadata de manera general. En este post vamos a hablar acerca de como es que funciona Windows Comunication Foundation en conjunto con mi aplicación.

En primera instancia vamos a conversar acerca de como se relacionan WCF y mi aplicación. Vamos también a incluir otros componentes como el Framework y el sistema operativo. La siguiente figura nos muestra como funcionan mi aplicacion en relación a todas las partes que intervienen cuando se envía una solicitud de mensaje y cuando la otra parte recibe esta solicitud.

imageComo podemos ver, todo inicia con la aplicación que nosotros construimos y que se va a encargar de enviar una solicitud de mensaje – cliente - al host del servicio. Este envío utiliza los assemblies de WCF, los cuáles tienen como objetivo facilitar el desarrollo de mis aplicaciones orientadas a servicios. Físicamente, WCF es un grupo de assemblies que exponen tipos y funcionalidades. Estos tipos y estas funcionalidades me permiten desarrollar aplicaciones sin preocuparme por la plomería necesaria para hacer que el mensaje que yo voy a enviar al host llegue sin problemas. Cuando hablo de plomería me refiero a las actividades relacionadas con abrir y cerrar la conexión, rutear el mensaje, seguridad del mensaje, etc. Por supuesto, WCF esta desarrollado sobre el framework de .NET, el cual a su vez utiliza las API’s del sistema operativo para poder llevar a cabo todas sus tareas.

Del otro lado, en el host de un servicio desarrollado en WCF sucede lo mismo. Un mensaje llega, y WCF, a través del sistema operativo y utilizando el framework de .NET, procesa el mensaje y de ser necesario, construye y envía una respuesta.

Así es como se relaciona WCF con el resto de los componentes necesarios para poder construir aplicaciones que utilizan servicios. En el próximo post vamos a conversar acerca de la arquitectura de WCF.

2.12.2009

¿Qué es WCF ? – Parte 2

En el post anterior publicamos el primer post acerca de lo que es WCF. En este post vamos a continuar con la parte 2 de esta serie de articulos.

En el contrato especificado en el post de la parte 1, usamos un tipo de retorno del tipo List<Usuario>. Usuario es una clase que escribí que representa una entidad de negocios la cual me permite almacenar los datos en detalle que acepto o envio desde el servicio generado. La estructura de este objeto como veremos en un post posterior va a viajar en formato XML con el wsdl, para que el consumidor del servicio tenga acceso al tipo de datos predefinido como tipo de retorno en mi servicio. Esta información del servicio en conjunto con el detalle del endpoint – definido en el post anterior – van a conformar la metadata del servicio.

Hay que tomar en cuenta que para que el “Usuario” vaya por la red, este debe de ser serializable. Ser serializable significa que el estado del objeto en un momento determinado puede ser persistido en algún medio, ya sea un archivo o un stream de bytes o en una instancia de una clase ya activa (Si nosotros como humanos fueramos serializables, entonces podríamos teletransportarnos :) ).

Con esta metadata del servicio, un consumidor del servicio puede ahora generar un Proxy. Ahora, ¿qué es un proxy en este contexto? Un proxy en WCF es un cliente generado a partir de la metadata expuesta por el servicio que hereda de la clase ClientBase<T>, por ejemplo:

[System.Diagnostics.DebuggerStepThroughAttribute( )]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
public partial class ServiciosSeguridadClient : System.ServiceModel.ClientBase<WPF_ClienteSeguridad.ReferenciaServiciosDeSeguridad.IServiciosSeguridad>, WPF_ClienteSeguridad.ReferenciaServiciosDeSeguridad.IServiciosSeguridad




Este proxy nos abstrae toda la lógica necesaria para conectarse con el servicio que se desea consumir, desde el manejo de la dirección del servcio a consumir hasta el endpoint necesario para poder conversar con el servicio. Igualmente, cuando tenemos tipos compuestos en el retorno o en los parámetros del servicio, estos tipos son generados automáticamente por el proxy para así poder utilizarlos del lado del cliente, es decir, para que la aplicación que consume el servicio “compile” cuando utilizamos el servicio. Podemos decir entonces, que el proxy es un puente que nos expone todas las operaciones en un servicio, y abstrae la serialización y el envío a traves de la red. Finalmente debemos decir que un proxy utiliza un único endpoint.



Por último, el cliente y el host hablan entre sí a través de varios canales. Además, alrededor de estos canales, se pueden tener comportamientos – behaviors – asociados con el servicio. Un canal es el medio por el cual el mensaje viaja entre el cliente y el ente que hostea el servicio. La comunicación se lleva a través de de un modelo conocido como el channel stack el cual estaremos revisando en detalle en post posteriores. Un comportamiento sirve para modificar un mensaje cuando el mensaje viaja por el channel stack.



En resumen podemos decir que vamos a tener un cliente y un host los cuales se ponen de acuerdo en un contrato. El host expone endpoints los cuales tienen una combinación de dirección, binding y contrato – ABC. El cliente utiliza un proxy que esta ligado a un endpoint, por lo tanto esta ligado a un contrato en particular. Por último, todos los detalles relacionados con la comunicación se abstraen a través de los canales y los comportamientos.



En el siguiente post vamos a profundizar en el tema del channel stack para comprender como es que funciona la parte de comunicación en WCF.

2.08.2009

¿Qué es WCF? – Parte 1

Una de las preguntas más comúnes cuando hablamos de servicios y arquitecturas orientadas a servicios en tecnologías Microsoft es: ¿Qué es WCF? Pues vamos a tratar de dar una breve introducción referente a que es WCF.

WCF significa Windows Comunication Foundation. Esta disponible desde la versión 3.0 del framework de .NET. Muchos gurús de SOA incluso dicen que WCF es un framework aparte al framework de .NET – algo con lo que coincido – escencialmente por que el framework de .NET conoce de componentes y no de servicios.

Se preguntarán entonces, para que otra forma de comunicación entre componentes si ya hemos tenido DCOM, Remoting, Servicios Web, WSE, etc. La respuesta corta a esta pregunta es SOA. WCF es diferente de las versiones anteriores antes mencionadas para comunicar componentes. Aunque ya definimos que es SOA en este post, vamos a simplificarlo para explicar que es WCF y por que es tan diferente como estamos intentando explicarlo. Pensemos en SOA como diferentes piezas de código ( servicios ) que estan corriendo alrededor del mundo y los clientes pueden hacer uso de estos servicios ( consumirlos ). El ente que hostea el servicio lleva a cabo las complejidades internas, y la infraestructura de comunicación  permite cosas tales como versionamiento, seguridad, ruteo, etc. Así, uno de los principales doctrinas de SOA es el aislamiento. ¿Por qué? Vamos a decir que estamos consumiendo un servicio web que acepta un parámetro cédula de identidad para buscar una persona en una base de datos de cliente y que este servicio retorna la persona encontrada. Todo lo que tiene que tiene que hacer el cliente es preocuparse por el parámetro de ingreso y por el dato que se le va a regresar. Más allá de este modelo solicitud/respuesta, el hosteador del servicio nunca habla con el cliente. Es por esto que decimos que existe una asilamiento entre el cliente y el servidor, y ellos interoperan solamente con lo acordado para interoperar es decir, el contrato.

En WCF se utiliza el término contrato para referirse a lo que el servicio hace. Usualmente en WCF un contrato es implementado como una interface decorado por el atributo [ServiceContract]. Un contrato por ejemplo luce como el siguiente código.

[ServiceContract]
public interface IServiciosSeguridad
{
[OperationContract]
List<Usuario> ObtenerUsuarios( );

}



En realidad se requieren al menos 3 piezas de información antes de poder utilizar un servicio:





  • La dirección: donde puedo encontrar el servicio.




  • El binding: cuál protocolo utilizar para poder consumir este servicio.




  • El contrato: cuando ya se donde esta el servcicio, y como voy a conversar con él, el contrato me dice que puedo hacer con el servicio.




Esto en WCF es conocido como el ABC ( Address, Binding, Contract) del servicio. Estos 3 componentes juntos conforman lo que se conoce como un EndPoint. Un EndPoint es como el que expone el servicio ( host del servicio ) expone un servicio para que muchos clientes puedan invocar las operaciones definidas en el contrato.



En el siguiente post vamos a seguir conversando acerca de WCF, principalmente de Proxies, canales y comportamientos.



 



2.02.2009

Controles para Silverlight – Mac Style

Normalmente no escribo acerca de controles o utilidades de terceros que yo utilizo para desarrollar aplicaciones en .NET, pero esta vez voy a hacer una excepción. Esta excepión se debe a que estoy utilizando un par de controles para silverlight que me parecen impresionantes. Esto son los controles de WebAqua. Estos controles me permiten tener un desktop web con el “look and feel” del sistema operativo de Mac Leopard.

En realidad son dos controles que me permiten tener formas de navegación idénticas al MacOS. El primero es el WebFishEye, que es algo así como el toolbar de aplicaciones que aparece en las Mac. La siguiente figura es un ejemplo de una aplicación WEB que utiliza este control. Si quieres ver el demo funcional, aquí lo puedes probar.

image

El segundo control es el WebCoverFlow, el cual permite tener una interface similar al del IPhone para desplegar imágenes. En la siguiente figura se puede ver una combinación del WebVoverFlow y el WebFishEye funcionando. Si quieres ver el demo funcional lo puedes ver aquí.

image

Espero les sirva para futuros desarrollos web.

1.18.2009

El Rol del Entity Framework en una Arquitectura n-layer

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.