Seleccionar un estilo AOP

Si decide que usar un aspecto es el mejor enfoque para una tarea determinada, ¿cómo sabe si usar Spring AOP o AspectJ, y si debe elegir el estilo de lenguaje (código) de Aspect, el estilo de anotación @AspectJ o ¿El estilo Spring XML? Esta elección está influenciada por una serie de factores, incluidos los requisitos de la aplicación, las herramientas de desarrollo y la familiaridad del equipo con AOP.

¿Spring AOP o AspectJ con todas las funciones?

Utilice la solución más sencilla que funcione. Spring AOP es más fácil de usar que AspectJ con todas las funciones porque no es necesario implementar la herramienta de compilación/enlace de AspectJ en los procesos de desarrollo y compilación. Si solo necesita administrar la ejecución de operaciones en Spring Beans, Spring AOP es la opción correcta. Si necesita brindar asesoramiento a objetos que no están bajo el control del contenedor Spring (por ejemplo, objetos de dominio, generalmente), entonces debe usar AspectJ. También debe utilizar AspectJ si necesita proporcionar sugerencias para unir puntos que no sean ejecuciones de métodos simples (por ejemplo, obtención de campo o establecimiento de puntos de unión, etc.).

Si utiliza AspectJ, puede elegir entre la sintaxis del lenguaje AspectJ (también conocida como "estilo de código") y el estilo de anotación @AspectJ. Obviamente, si no está utilizando Java 5+, entonces la elección ya está hecha: utilice un estilo de código. Si los aspectos juegan un papel importante en su proyecto y puede utilizar el complemento AspectJ Development Tools (AJDT) para Eclipse, la sintaxis del lenguaje AspectJ es la opción preferida. Es más limpio y sencillo porque el lenguaje fue diseñado específicamente para aspectos de escritura. Si no usa Eclipse o tiene solo algunos aspectos que no juegan un papel importante en la aplicación, podría considerar usar el estilo @AspectJ, seguir con la compilación Java normal en su IDE y agregar un paso de enlace de aspecto a su script de compilación.

¿@AspectJ o XML para Spring AOP?

Si decide utilizar Spring AOP, puede elegir entre el estilo @AspectJ o XML. Hay varias compensaciones a considerar.

El estilo XML puede resultar más familiar para los usuarios actuales de Spring y es compatible con verdaderos POJO. Cuando se utiliza AOP como herramienta para configurar servicios empresariales, XML puede ser una buena opción (la prueba adecuada sería responder a la pregunta si cree que la expresión de segmento será parte de su configuración y podría necesitar cambiarla de forma independiente). El estilo XML dejará más claro desde tu configuración qué aspectos están presentes en el sistema.

El estilo XML tiene dos desventajas. En primer lugar, no encapsula completamente la implementación del problema que resuelve en un solo lugar. El principio No te repitas/DRY establece que cada conocimiento debe tener una representación única, consistente y autorizada dentro del sistema. Cuando se utiliza el estilo XML, el conocimiento de cómo se implementa una tarea se distribuye entre la declaración de clase del bean base y XML en el archivo de configuración. Si usa el estilo @AspectJ, entonces esta información está contenida en un módulo: el aspecto. En segundo lugar, el estilo XML es un poco más limitado que el estilo @AspectJ en términos de expresividad: solo se admite el modelo de creación de instancias únicas de un aspecto y no es posible concatenar sectores con nombre declarados en XML. Por ejemplo, cuando utilices el estilo @AspectJ, podrías escribir algo como:

@Pointcut("execution(* get*())")
public void propertyAccess() {}
@Pointcut("execution(org.xyz.Account+ *(..))")
public void operationReturningAnAccount() {}
@Pointcut("propertyAccess() && operationReturningAnAccount()")
public void accountPropertyAccess() {}

@Pointcut("execution(* get*())")
fun propertyAccess() {}
@Pointcut("execution(org.xyz.Account+ *(..))")
fun operationReturningAnAccount() {}
@Pointcut("propertyAccess() && operationReturningAnAccount()")
fun accountPropertyAccess() {}}

Puedes declarar los dos primeros sectores en estilo XML:

<aop:pointcut id="propertyAccess"
        expression="execution(* get*())"/>
<aop:pointcut id="operationReturningAnAccount"
        expression="execution(org.xyz.Account+ *(..))"/>

La desventaja del enfoque XML es que no se puede definir un segmento accountPropertyAccess combinando estas definiciones.

El estilo @AspectJ admite modelos de creación de instancias adicionales y una composición de sectores más rica. Su ventaja es mantener el aspecto de una unidad modular. Otra ventaja es también que los aspectos @AspectJ pueden ser reconocidos (y por lo tanto utilizados) tanto por Spring AOP como por AspectJ. De esta manera, si luego decide que tareas adicionales requieren capacidades de AspectJ, puede cambiar fácilmente a la configuración clásica de AspectJ. En general, el equipo de Spring prefiere el estilo @AspectJ para aspectos especiales que van más allá de la simple configuración de servicios empresariales.

Uso mixto de tipos de aspectos

Es perfectamente aceptable mezclar y combinar aspectos en la misma configuración, escrita en el estilo @AspectJ, utilizando herramientas de proxy automático definidas por el esquema de aspecto <aop:aspect>, declararon los asesores. <aop:advisor> e incluso proxies e interceptores escritos en otros estilos. Todos se implementan utilizando el mismo mecanismo de soporte básico y pueden coexistir sin ningún problema.