Agregando referencias

Como primer paso veremos el uso de que librerías hay que utilizar para poder hacer uso de la programación orientada a aspectos. Yo he elegido Spring.Net pero se puede elegir cualquier otro framework, a mi me gusta Spring por la filosofía que tiene de poco dependencia de su código y que propone muy buenas soluciones en diferentes aspectos, como NHibernate y recientemente el nuevo proyecto, por cierto muy interesante, GemFire, una solución escalable de datos para grandes plataformas.

Paso a nombrar las DLLs que usaremos:

1. Spring.Aop.dll
2. Spring.Core.dll
3. log4net.dll (Log de debug)
4. Common.Logging.dll (Log)
5. Common.Logging.Log4Net.dll (Log)

A continuación elegiremos un proyecto para generar donde incluir estas dlls, ya puede ser un proyecto de consola, Windows Forms, WPF como en este caso…

Configurando Spring.Net

Lo primero que haremos será añadir un fichero de configuración App.config o Web.config, el único inconveniente que tiene Spring.Net es que la configuración puede aumentar bastante de tamaño dependiendo del numero de objetos que queramos declarar en su contexto, por ello me gusta separar la declaración de objetos en uno o varios ficheros independientes fuera del config

<!-- Spring -->
  <spring>
    <context>
      <resource uri="~/Config/Spring.xml"/>
    </context>
  </spring>

El archivo Spring.xml habrá que ponerlo como contenido y que se copie siempre en el directorio para que pueda encontrarlo y realizar la carga de los objetos del contexto.

Esta es mi declaración de los Advisors (que realizaran las funciones dependiendo del tipo de Advisor que sean, antes de la llamada, después, durante…)

<object id="loggingBeforeAdvice"

        type="aopSample.Desktop.Advisors.LoggingBeforeAdvice,

         aopSample.Desktop">

</object>

<object id="loggingAfterAdvice"

        type="aopSample.Desktop.Advisors.LoggingAfterAdvice,

        aopSample.Desktop">
</object>
<object id="exceptionThrowsAdvice"

        type="aopSample.Desktop.Advisors.ExceptionThrowsAdvice,

        aopSample.Desktop"

</object>

Como veis lo único que hago es declarar cada clase con un identificador y el tipo que se corresponde con mi clase para que lo maneje el contexto de Spring.net

Por último habrá que declarar el objeto en el que vamos a inyectar los aspectos y aquí es donde muestra su gran potencial

<object id="simpleServiceProxy" type="Spring.Aop.Framework.ProxyFactoryObject">
    <property name="target">
      <object id="simpleService"

       type="aopSample.Desktop.Services.SimpleService, aopSample.Desktop" />
    </property>
    <property name="InterceptorNames">
      <list>
        <value>loggingBeforeAdvice</value>
        <value>loggingAfterAdvice</value>
        <value>exceptionThrowsAdvice</value>
      </list>
    </property>
  </object>

Como vemos lo que hacemos es declarar el Proxy que se encarga de generar la factory de spring ProxyFactoryObject que envuelve nuestro objeto declarado en el target e inyectarle los Advisors que ejecutara.

Como vimos en el post anterior hay muchas clases para poder usar la AOP, pero Spring nos simplifica bastante este paso mediente la configuración creando todas estas clases intermedias el solo.

Es muy importante generar una interfaz de nuestro simpleService, para que Spring.Net puede realizar las llamadas a nuestros Advisors, ya sea con Refactor-> Extract Interface o manualmente.

Probando nuestro proyecto

Lo primero que haremos será crear el contexto de Spring

IApplicationContext 

_ctx = ContextRegistry.GetContext();

Y luego pedirle a Spring nuestro objeto proxy y realizar la llamada a un método para que lanze nuestros Advisor y ver que funcionen

ISimpleService simpleService =

               _ctx.GetObject("simpleServiceProxy") as ISimpleService;
  simpleService.DoSomethingComplex();

Por ultimo y para que todo esto funcione deberemos haber creado nuestros Advisors que lo único que requieren es que se implemente una interfaz dependiendo del tipo de advisor que queramos crear que los tenéis declarados aquí Advice Types

Os dejo el proyecto para que podáis descargarlo y probar el funcionamiento con todas las partes montadas. 
Descargar

Un saludo espero que os haya gustado 🙂

El porque de la programación orientada a Aspectos

La programación orientada a aspectos o Aspect Oriented Programming (AOP), surge de la necesidad de complementar ciertos aspectos de la programación orientada a objetos que esta no puede cumplir.

La programación orientada a objetos trata de encapsular la funcionalidad en clases para que sean fácilmente reutilizables y encapsulen la lógica de un determinado proceso. Pero que me decís de aquella funcionalidad que no puede ser encapsulada en una determinada clase sino que es compartida por varias características de la aplicación. Como puede ser el logging, el tratamiento de transacciones, tratamiento de excepciones…

En estos casos es necesario incrustar código de las partes de logging y del manejo de transacciones por ejemplo dentro de nuestras clases de acceso a datos, con el inconviente que se crea un acoplamiento entre los distintos módulos de nuestra aplicación y que la modificación en alguno de ellos normalmente repercute en los otros. Aquí es donde interviene la programación orientada a aspectos para tratar de desacoplar y independizar los distintos módulos de nuestra aplicación.

Ventajas de la programación orientada a aspectos

La programación orientada a aspectos provee un mecanismo para separar casa uno de los módulos de nuestra aplicación y poder hacer llamadas entre ellos de una manera mas limpia.

• Evita que se duplique código, por ejemplo para hacer una auditoria cada vez que se modifique una de las propiedades de nuestras clases, habría que duplicar la llamada a nuestra clase de auditoria en cada una de ellas.
• Mejora el testeo de nuestras aplicaciones pudiendo testear aspectos de nuestra aplicación de manera mas independiente pudiendo diferenciar mas rápidamente cual de los aspectos implicados en un modulo es el que falla.
• El mantenimiento del código también se vuelve mas flexible, ya que se en lugar de mostrar una ventana cada vez que salte una excepción simplemente queremos que lo indique es un fichero habría que cambiar esto en muchas partes de la aplicación.

Terminología AOP

Este método de programación, define una serie de términos para su funcionamiento:

• Advice (Aviso): Según el framework de AOP que utilicemos tendrá uno o otros, como por ejemplo Advices a la entrada y salida de los métodos, antes de la llamada al método… Cada uno de nuestros advices implementaran los distintos aspectos de nuestra aplicación, un advice de logging otro de transacciones…
• Joinpoints (Puntos de unión): Aquí es donde se invoca al Advice y realizar llamadas entre distintos aspectos de nuestra aplicación. Dentro del método de guardado de nuestro cliente la llamada a la gestión de transacciones.
• Pointcut: Los pointcuts son agrupaciones de varios jointpoints de nuestra aplicación, por ejemplo si queremos que en el set de todas las propiedades de una clase llame al Advice de Auditoria.
• Interceptors (Interceptores): Estos son los encargados de realizar las llamadas a nuestros advices desde nuestros pointcuts.
• Target (Advised object): Es el objeto que contiene los pointcuts como por ejemplo nuestro CustomerDAO
• Proxy: Esta es una clase intermedia de nuestros Target y nuestros Advices, que trata de encadenar las llamadas entre uno y otro.

Todas estas clases las provee el framework de AOP que estemos usando así que no os asustéis a no ser que queráis implementar vuestro propio framework ;-). Nosotros tendremos que programar lo mismo pero pensando en que van a ser independientes y las llamadas entre si las haremos configurando el AOP.

Puntos a desarrollar

• Eliminar las llamadas entre nuestras distintas clases para hacerlos advices y poder ser llamados con nuestro framework de AOP.
• Determinar los pointcuts, agrupar todas las llamadas que queremos hacer a un determinado advice para cada una de nuestras clases.
• Definir el Interceptor que intercepte y realice las llamadas a nuestros Advices.
• Definir el proxy para cada una de nuestras clases que se encargue de gestionar la conexión entre ambos elementos.

De momento dejo aquí la introducción a la programación orientada a aspectos el próximo post pondré un ejemplo haciendo uso de Spring.Net, ya que soy un usuario de NHibernate y realmente mejora su uso por ejemplo en la gestión de transacciones una maravilla!!!.

Un saludo

[tweetmeme source=”mingue” only_single=false]

En el ultimo keynote de Google I/O, se vio como hacían uso de las waves por ejemplo para incrustar una wave y usarla de moderación para los eventos en directo, donde los usuarios daban su opinión añadiendo casi cualquier tipo de elementos.

Y es que google Wave tiene muchas extensiones nuevas y aunque su uso pudo defraudar un poco al principio el uso de una tecnología tan innovadora le cuesta hacerse hueco entre el uso diario, pero sin duda no esta muerto y avanza rápidamente.

Aquí tenéis un ejemplo de una wave incrustada de la ultima Google I/O

http://code.google.com/intl/es-ES/events/io/2010/wave.html

Incrustaría una aquí pero WordPress no deja 😦

Con la siguiente url podéis incrustar cualquier wave en vuestro blog http://www.google.com/webelements/wave/. Como por ejemplo seguir algún evento en directo, y dejando atrás a twitter para ello que no esta mal pero no ofrece lo mismo que Wave para estas cosas.

Otros ejemplos de plugins para Google Wave que tienen el éxito asegurado

[tweetmeme source=”mingue” only_single=false]

Primera Parte

Segunda Parte

Puntos fuertes y flacos de Silverlight

Como vimos en la primera parte, el tema de diseño de las aplicaciones con Expression Blend esta muy bien logrado ya que te permite hacer casi cualquier cosa en muy poco tiempo.

En cambio en cuanto al framework, la verdad es que las posibilidades de hacer cualquier cosa se reducen bastante, de ahí, que haya tardado tiempo en implementar esta segunda parte y es que perdí un poco el interés, al observar un framework muy reducido.

Mi primera intención fue tratar de obtener los datos a través de la api de Twitter haciendo una llamada a sus servicios. Iluso de mi al intentar hacer la llamada a la api salto una SecurityException que me dijo que no era el camino correcto, pero seguí en mis trece pensando que podría ser algún error en la llamada. Descubrí que las llamadas entre dominios no están permitidas con Silverlight y por lo que pude averiguar en el servidor donde realizas la petición debe de existir un archivo crossdomain.XML, que indique las restricciones de seguridad. Para sorpresa de mi ese archivo existía en Twitter. y revisando el XML vi que las llamadas a la API estaban permitidas desde cualquier dominio.

<?XML versión="1.0" encoding="UTF-8"?>
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
  <allow-access-from domain="twitter.com" />
    <allow-access-from domain="api.twitter.com" />
    <allow-access-from domain="search.twitter.com" />
    <allow-access-from domain="static.twitter.com" />
    <site-control permitted-cross-domain-policies="master-only"/>
  <allow-http-request-headers-from domain="*.twitter.com" headers="*" secure="true"/>
</cross-domain-policy>

Así que probé el mismo código realizando un servicio web desde WCF, para sorpresa mía de nuevo funciono correctamente. Entonces cual es el inconveniente restricciones del framework por ¿¿seguridad?? que sentido tiene no poder consumir servicios de otros dominios, hay algo mas que configurar que me he perdido??.

La verdad es que viendo que funcionaba en WCF decidí no perder mas tiempo en investigar ya que tenia a Silverlight un poco por debajo de mis expectativa y no quería saber mas.

Accediendo a la API de Twitter

Así que definí el siguiente servicio en WCF.

public class TwitterService : ITwitterService
{
  public List<TwitterItem> GetTwitterTimeLine(string username)  
  {
   WebClient webClient = new WebClient();
   string result = webClient.DownloadString(
   new Uri("http://api.twitter.com/1/statuses/user_timeline.XML?screen_name=" + username));
   XElement xmlElement = XElement.Parse(result);
   var itemList = from t in xmlElement.Descendants("status")
               select new TwitterItem
               {
               UserName = t.Element("user").Element("screen_name").Value,
               Message = t.Element("text").Value,
               ImageSource = t.Element("user").Element("profile_image_url").Value
               };
   return itemList.ToList();
   }
 }

Posteriormente referencie mi servicio desde mi aplicación Silverlight.

 

Para mi sorpresa lo que devolvía no era una List<TwitterItem> como cabria esperar sino que la habría transformado en una ObservableCollection (especializada para los databindings). Han adivinado que quería hacer un databinding? En fin me vino bien en este caso.

Así que le asigne los datos y aparecieron en mi control

En el próximo post explicare, como realizar el DataTemplate para que salgan formateados los tweets y como editar la scrollbar para que sea acorde con la apariencia de nuestra aplicación como se ve en la imagen :-).

 

Ah y pondré los fuentes del proyecto!!!

[tweetmeme source=”mingue” only_single=false]

Google docs ha sacado una nueva herramienta de dibujo para poder hacer diagramas donde varias personas podamos ir modificando y viendo las modificaciones al mismo tiempo como en el resto de herramientas.

Ha esta herramientas se le puede sacar mucho rendimiento para hacer diagramas de arquitectura de software o de modelado de datos de una manera mas eficaz y aportando ideas de cada uno de los miembros del desarrollo.

Gran idea de google y no se ha oído mucho por ahí, bravo por ellos 🙂

[tweetmeme source=”mingue” only_single=false]