Spring AOP y AspectJ

Usualmente cuando empezamos un proyecto con Spring no tomamos mucha importancia a la librería que utilizaremos, debido a que la suite de Spring provee por defecto su propia implementación (Spring AOP), la cual es facil de adoptar y nos brinda solución a los problemas mas comunes relacionados con la programación orientada a aspectos.

Todo va excelente en el proyecto, hasta que por requerimientos del negocio necesitamos crear aspectos propios para tareas específicas, y empezamos a tener ciertos problemas, como la no ejecución de los aspectos sobre métodos anidados, y nos preguntamos si estamos haciendo algo mal en nuestro código o en una configuración, pues no es así, los aspectos de Spring no funcionan sobre métodos anidados debido a que su implementación hace uso de proxies y cuando llamamos a métodos dentro de la misma clase estos proxies no son usados, ello quiere decir que los aspectos solo funcionan sobre métodos que son invocados desde otros objetos que también son administrados por Spring.

Estas situaciones permiten que los desarrolladores encuentren soluciones creativas, como mover los métodos observados a otro beans para que funcionen sus aspectos.

Tal vez al inicio no lo notemos, pero a la larga esto generará que la responsabilidad que se había definido inicialmente en un bean se encuentre dispersa en diversos beans para solucionar la limitación de Spring AOP. 

Si revisamos Spring AOP a más detalle nos daremos con la sorpresa que la implementación de Spring es solo una solución simple y de fácil entendimiento para solucionar los problemas más comunes; aquí es donde AspectJ entra en el juego.

A diferencia de Spring AOP, AspectJ provee la solución completa de AOP haciéndola más compleja pero a su vez más potente y robusta.

Mientras más revisamos las bondades de AspectJ notamos más deficiencias de Spring AOP como que solo funciona para un tipo de joinpoint (“method execution”), también que no es aplicable sobre clases y métodos declarados como final, entre otros.

A continuación listamos las principales diferencias entre ambas implementaciones.

Entonces si todo es tan bueno con AspectJ, ¿por qué no lo usamos desde el principio?, como se mencionó anteriormente, es un poco más complejo trabajar con Aspectj y según la configuración que tengamos puede o no usar un compilador adicional para los aspectos.

Con el análisis realizado no estamos sugiriendo que la implementación de Spring sea mala, ya que es una muy buena herramienta que funciona correctamente y está enfocado en los problemas más comunes que solemos tener en los proyectos, pero si necesitamos algo más complejo para nuestro proyecto deberíamos revisar a más detalle AspectJ.

Siguiendo con el tema de aspectos, el equipo ha creado otro artículo interesante donde vemos AspectJ en acción.

Articulos Relacionados

• AspectJ en Acción