7.26.2009

Versionando Aplicaciones – Unity – Parte 3

Continuando con la serie de post acerca de IoC – contenedores de dependency injection – en este post vamos a examinar Unity, el cual es un application block que esta disponible gratuitamente desde el sitio de codeplex o a través del sitio de pattern and practices.

Al igual que cualquier otro IoC container, lo que busca unity es desasociar o eliminar la dependencia que existe entre las clases y “mover” esa dependencia a las interfaces. La ventaja con esto en un IoC, es que básicamente al depender de una interface, podemos cambiar la implementación de esa interface en cualquier momento sin necesidad de recompilar la aplicación sino más bien a través de configuración – lo único que necesitamos es cumplir con el contrato.

Trabajando con Unity

En esta ocasión vamos a implementar el mismo ejemplo que presentamos con CastleWindsor del cual presentamos el modelo a continuación:

image El primer paso para hacer funcionar Unity es agregar las referencias necesarias para tener acceso a Unity.

image

Una vez agregadas las referencias, vamos a construir el código necesario para crear la instancia de la clase DoSearch con la alerta del tipo IAlert instanciada utilizando Unity.

image En el código anterior, procedemos a registrar un tipo para el contrato IAlert, en este caso SMSAlert, lo cual nos permite crear una instancia de la clase SearchManager y proceder a asignarle la alerta que corresponde, en este caso utilizamos el metodo Resolve del contenedor. Cuando ejecutamos el código anterior, Unity sabe cual clase tiene que instanciar y procede como se muestra en la siguiente figura.

image El ejemplo anterior no es muy funcional en el sentido de que solamente tenemos una clase para registrar y por lo tanto a la hora de resolver cual clase instanciar, el contenedor solamente debe de instanciar la clase default registrada con el tipo. En el siguiente ejemplo vamos a registrar ambas implementaciones de IAlert con lo cual tendremos que elegir que instancia crear en tiempo de ejecución. Si registramos otro tipo despues de la alerta SMS, entonces el tipo que se instanciaría sería el último registrado.

image El resultado sería el siguiente:

image

La solución para poder elegir cual clase instanciar es especificar un nombre para cada mapa que se va a crear, y a la hora de crear la instancia procedemos a elegir vía ese nombre de mapa, cual tipo instanciar.

image

En este caso especificamos los nombres de SMS y EMail para los mapas y decidimos utilizar SMS. El resultado es el siguiente:

image

Con lo especificado hasta este momento, podemos crear un software factory muy sencillo basándonos en el nombre de la etiqueta del mapa y guardando el nombre en un archivo de configuración o algún medio que permita cambiar la clase a instanciar en tiempo de ejecución.

Pese a lo anterior, Unity nos permite registrar los tipos que vamos a utilizar en un archivo .config y crear las instancias en base a los registrios de los tipos hechos en este archivo. El siguiente ejemplo nos muestra como llevar a cabo esta tarea.

image

En primera instancia se deben agregar las referencias para poder acceder a la configuración del app.config – System.Configuration – y a la configuración de Unity – Unity.Configuration.

image  El siguiente paso es codificar la instanciación de la clase deseada. Para esto, accedemos al archivo de configuración a través del ConfigurationManager y procedemos a configurar la sección de Unity. Seguidamente creamos la clase y procedemos a resolver el tipo. Nótese que en este caso, le indicamos a Unity a través del método Resolve, que queremos una instancia con la etiqueta “SMS”, la cual vamos a agregar al archivo config seguidamente.

image

Primeramente procedemos a registrar la sección que vamos a llamar unity – podríamos llamarla como queramos – y vamos a indicar que assembly para configuración de Unity vamos a utilizar.

Seguidamente procedemos a crear “alias” de los contratos que vamos a instanciar – en este caso IAlert. Por último, dentro de la sección container, agregamos los tipos mapeados para poder instanciarlos. Como podemos ver, en este caso mapeamos SMSAlert a IAlert y le pusimos de nombre SMS, el cual es el nombre que vamos a utililizar para crear la instancia. El nombre PruebaCastleWindsor es el nombre del assembly que se genera y en donde residen los tipos – en este caso una aplicación de consola – y lleva ese nombre porque en el mismo proyecto donde estoy haciendo uso de Unity, hice la prueba de CastleWindsor. El resultado al ejecutar la aplicación es el siguiente:

image

Como hemos visto, Unity también nos sirve para crear aplicaciones fáciles de versionar en tiempo de ejecución – al decir versionar me refiero a instanciar los componentes de negocio que necesitamos dependiendo de reglas de configuración pre establecidas. En post posteriores vamos a ahondar en el uso de Unity.

Technorati Tags: ,,

7.04.2009

El OracleClient NO va más

Para muchos de nosotros que hemos desarrollado – o que estamos o vamos a desarrollar - aplicaciones en .NET que usan como repositorio de datos la base de datos Oracle, esta noticia nos tiene que importar.

Resulta ser que el grupo que desarrolla ADO.NET ha decidido dejar por fuera de ADO.NET el componente de OracleClient - System.Data.OracleClient – nativo de ADO.NET. Esto por considerar que la mayoría de los clientes de Microsoft, utilizan proveedores de terceros para conectarse a las bases de datos Oracle.

En el framework 4.0 será la última vez que veamos este provider de forma nativa en el framework, y será marcado como “deprecated”.

Aunque creo que esta noticia nos impacta a todos los que estamos desarrollando aplicaciones contra bases de datos Oracle, es bueno que se de con suficiente tiempo para tomar en consideración esta situación.

La noticia en detalle la pueden encontrar aquí.