Mapeo Sencillo Con Configuración AOP De Spring Framework

Mapeo Sencillo con Configuración AOP de Spring Framework

Esta serie de documentos tiene por objetivo presentar ejemplos de tipos de mapeos que se pueden realizar con Hibernate 3 y Java Persistence API ( JPA ). La intención es cubrir paulatinamente con ejemplos desde los mapeos más sencillos, hasta los más complicados.

En este tercer documento se configura funcionalidad AOP a Spring Framework para automatizar el manejo de conexiones y transacciones en una aplicación, y de esta manera simplificar enormemente el código de persistencia de una aplicación empresarial.

Una aplicación que maneja manualmente el código de conexión a base de datos y las transacciones tiende a repetir mucho código “de plomería”. Especificaciones como EJB fueron diseñadas en principio para eliminar ese tipo de responsabilidades de los hombros del programador; pero como se muestra en este tutorial este tipo de soluciones no están limitadas a aplicaciones que son ejecutadas en un EJB container.

Código Repetido

Comencemos por analizar uno de los métodos que se ha venido utilizando hasta el momento para la inserción de un registro hacia la base de datos:

public int insertObject

( FacturaDTO factura )

{

Session session =

_sessionFactory.openSession();

try

{ insertObject( session, factura ); }

finally

{ session.close(); }

return factura.getId();

}

private void insertObject

( Session session, FacturaDTO factura )

{

boolean commit = false;

Transaction transaction =

session.beginTransaction();

try

{

session.save( factura );

commit = true;

}

finally

{

if( commit )

transaction.commit();

else

transaction.rollback();

}

}

El listado anterior contiene bloques de código que se repiten para métodos similares:

 El código de apertura y cierre de una conexión ( sesión ) siempre es el mismo para todos los métodos de la clase. Nótese que la sesión se abre al inicio del método, y se cierra en un bloque try/finally.

 El código de manejo de transacciones es el mismo para todos los métodos transaccionales de la clase. Por su parte, los métodos no transaccionales no incluyen este código.

Si se considera el efecto acumulado del código que se repite en clases de lógica de negocio, aún tan sencillas como las que se muestran en estos tutoriales, el efecto acumulado es considerable, y oscurece la lógica de negocio propia de la aplicación.

Lo ideal en este caso es poder reutilizar de alguna manera todo este código. La pregunta es ¿ cómo ?

El tipo de código repetido que se maneja en estas clases no es fácil de extraer por medio de estrategias básicas en programación orientada a objetos como son el manejo de delegación o de herencia. Esto se debe a que este tipo de código no se presta a ser separado al estar inmerso en métodos diferentes con firmas diferentes.

La aplicación de algunos patrones de diseño específicos pueden ayudar a extraer efectivamente este código, aunque en este caso se requerirá implementar arquitecturas particulares en un desarrollo. A veces la complejidad introducida por una arquitectura no justifica su aplicación; y en ocasiones sí lo justificará. Sin embargo, la pregunta sigue en el aire: ¿ existe una alternativa sencilla y práctica de reutilizar este código ?

Aspect Oriented Programming ( AOP )

La programación por aspectos es una extensión de la programación orientada a objetos ( OOP ), y buscar resolver problemas de reuso de código en situaciones en que ni la herencia ni la delegación pueden ser utilizadas de forma satisfactoria. El ejemplo de reuso de código de conexiones y transacciones es una muestra de un tipo de estas situaciones.

A este tipo de código que se repite en diferentes métodos de diferentes clases en una aplicación, cuando dichos métodos no tienen relación alguna entre sí ( en el tipo de interfase que usan, los parámetros que reciben y sus valores de retorno ) se le denomina típicamente crosscutting concerns. Además de los ejemplos que se han dado, otros ejemplos de este tipo de código es el manejo de seguridad declarativa, manejo de bitácoras, código de auditoría, manejo remoto de objetos, mecanismos transparentes de activación / pasivación de servicios, etc.

Una de las características más importantes dentro de AOP es la habilidad de definir interceptores; esto es, código que se ejecute siempre alrededor de otro de forma transparente hacia el cliente. Suponiendo que un método contiene la lógica necesaria para la inserción de datos hacia una tabla, el código que abre y cierra la conexión, y que hace el procesamiento de transacciones se puede definir en un interceptor como se muestra en la siguiente imagen:

Este mecanismo permite extraer todo el código repetido en los métodos de la claseObjectManagerImpl.

Mejor aún, el mismo interceptor puede ser aplicado a diferentes clases con diferentes métodos que requieran extraer el código repetido en todas ellas:

En pocas palabras, un mismo interceptor puede ser reusado sobre múltiples clases de lógica de negocio en una aplicación.

La clave para que el manejo de interceptores AOP sea transparente a un cliente está en el manejo de interfases para las clases que implementan el servicio. Si el cliente dependiera directamente de una implementación, sería más difícil agregar un intermediario que ejecutara la lógica para el manejo de conexiones y transacciones:

En cambio, desde tutoriales pasados se ha insistido que el cliente dependa de una interfase (ObjectManager ) y no de una implementación ( ObjectManagerImpl ):

En un escenario de este estilo, cuando aún no se han definido interceptores a un programa, lasinvocaciones se realizan directamente sobre la implementación; aunque la dependencia que se tiene en la clase cliente se realiza sobre la interfase. Entender con claridad este punto es esencial.

Podemos ver la dependencia que el cliente sobre la interfase ( y no la implementación ), si verificamos el siguiente fragmento de código asociado a la clase Test.java:

/**

* Método de ejecución de altas, bajas,

* cambios y consultas.

*/

...