Tengo la impresión de que Spring AOP se utiliza mejor para tareas específicas de la aplicación, como seguridad, registro, transacciones, etc., ya que utiliza anotaciones Java5 personalizadas como marco. Sin embargo, AspectJ parece ser más amigable con los patrones de diseño.Spring AOP frente a AspectJ
¿Alguien puede resaltar los diversos pros y contras del uso de Spring AOP frente a AspectJ en una aplicación de Spring?
Primavera-AOP Pros
Es más sencillo de usar que AspectJ, ya que no tiene que utilizar LTW (load-time weaving) o el compilador AspectJ.
Se utiliza el patrón de proxy y el decorador patrón
Primavera-AOP Cons
AspectJ Pros
AspectJ Contras
Esto no es correcto @Configurable permite que – Marc
@Configurable requiera el uso de AspecJ a través de Spring. De los documentos: 'Si necesita aconsejar objetos que no están administrados por el contenedor de Spring (como por ejemplo, los objetos de dominio), necesitará usar AspectJ.' – HDave
otra con la primavera-AOP para mí son los largos stacktraces ilegibles debido a la parte confusa basado en proxy enfoque – wrm
The spring user manual dará una gran cantidad de información, directamente de la boca del caballo.
El capítulo 6.4 - Choosing which AOP declaration style to use está muerto para usted, ya que analiza los pros y los contras de ambos.
El párrafo 6.1.2 - Spring AOP Capabilites and goals & capítulos 6.2 - @Aspect support y 6.8 - Using AspectJ with Spring applications deben ser particularily interesante.
Aparte de lo que ya han dicho otros - sólo para reformular, there are two major differences:
Primavera-AOP: Runtime tejido a través de proxy utilizando el concepto de dynamic proxy if interface exists or cglib library if direct implementation provided.
AspectJ: tiempo de compilación si el tejido a través AspectJ Java Tools(ajc compiler) fuente disponible o post recopilatorio tejer (utilizando archivos compilados). Además, se puede habilitar el tiempo de carga con Spring: se necesita el archivo de definición aspectj y ofrece flexibilidad.
tiempo de compilación de tejido puede ofrecer beneficios de rendimiento (en algunos casos) y también el joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.
Una nota adicional: Si el rendimiento con una carga elevada es importante, tendrá que AspectJ que es más rápido que 9-35x Spring AOP. 10ns vs 355ns podría no parecer mucho, pero he visto personas usando MUCHOS Aspectos. 10K de aspectos. En estos casos, su solicitud puede alcanzar miles de aspectos. En ese caso, está agregando ms a esa solicitud.
Véase el benchmarks.
https://web.archive.org/web/20150520175004/https://docs.codehaus.org/display/AW/AOP+Benchmark – Ian
Spring AOP es una de las partes esenciales de la estructura de muelles. En la etapa muy básica, el marco de primavera se basa en IoC y AOP. En el curso oficial de Spring hay una diapositiva en la que dice:
El AOP es una de las partes más importantes del framework.
El punto clave para entender cómo AOP en la primavera funciona es que cuando se escribe un aspecto con la primavera que instrumento del marco con la construcción de un proxy para sus objetos, con un JDKDynamicProxy si su bean implementa una interfaz o mediante CGLIB si su bean no implementa ninguna interfaz. Recuerde que debe tener cglib 2.2 en su class-path si está utilizando Spring antes de la versión 3.2. A partir de Spring 3.2 es inútil porque cglib 2.2 se incluyó en el núcleo.
El marco en la creación de frijol crearán un proxy que envuelve los objetos y añade transversales responsabilidades preocupaciones de corte tales como la seguridad, la gestión de transacciones, registro y así sucesivamente.
La creación de proxy de esta manera se aplicará a partir de una expresión punto de corte que los instrumentos del marco para decidir qué habas y los métodos se creará como proxies. El consejo será más responsable que tu código. Recuerde que en este proceso el punto de corte captura solo los métodos públicos que no se declaran como finales.
Ahora, mientras que en Spring AOP, el Tejido de Aspectos será realizado por el contenedor al inicio del contenedor, en AspectJ tiene que realizar esto con una compilación posterior de su código a través de la modificación del código de bytes. Por esta razón, en mi opinión, el enfoque de Spring es más simple y más manejable que AspectJ.
Por otro lado, con el AOP primavera no se puede utilizar todo el poder de la AOP, porque la aplicación se realiza a través de servidores proxy y no con la modificación a través de su código.
Al igual que en AspectJ, puede usar tejido de tiempo de carga en SpringAOP. Puede beneficiarse de esta característica en la primavera se implementa con un agente y configuraciones especiales, @EnabledLoadWeaving o en XML. Puede usar el espacio de nombre como ejemplo. Sin embargo, en Spring AOP no puedes interceptar todos los casos. Por ejemplo, el comando new no es compatible con Spring AOP.
Sin embargo, en Spring AOP puede beneficiarse del uso de AspectJ mediante el uso del método de fábrica aspectof en el bean de configuración de primavera.
Por la razón de que Spring AOP es básicamente un proxy creado a partir del contenedor, por lo que puede usar AOP solo para beans de primavera. Mientras que con AspectJ puedes usar el aspecto en todos tus frijoles. Otro punto de comparación es la depuración y la previsibilidad del comportamiento del código. Con AOP de primavera, el trabajo se realiza desde el compilador de Java y los aspectos son una forma muy buena para crear un proxy para su Spring Bean. En AspectJ, si modificas el código, necesitas más compilación y entender dónde se tejen tus aspectos podría ser difícil. Incluso cerrar el tejido en primavera es más sencillo: con el muelle, se elimina el aspecto de la configuración, se reinicia y funciona. ¡En AspectJ debes recompilar el código!
En tejido de tiempo de carga, AspectJ es más flexible que Spring porque Spring no admite todas las opciones de AspectJ. Pero en mi opinión, si desea cambiar el proceso de creación de un bean, una mejor manera es administrar el inicio de sesión personalizado en una fábrica y no con el tejido en tiempo de carga de un aspecto que cambie el comportamiento de su nuevo operador.
espero que esta panorámica de AspectJ y primavera AOP ayuda a entender la diferencia de las dos pociones
Es importante tener en cuenta si sus aspectos serán misión crítica y donde se está implementando el código. Spring AOP significará que está confiando en el tejido de tiempo de carga. Esto puede fallar y, en mi experiencia, significa que pueden existir errores registrados, pero no evitará que la aplicación se ejecute sin el código de aspecto [Añadiría la advertencia de que es posible configurarlo de tal forma que esto no sea posible. el caso; pero personalmente no estoy al tanto de él]. El tejido en tiempo de compilación evita esto.
Además, si utiliza AspectJ junto con el aspectj-maven-plugin, entonces puede ejecutar pruebas de unidades contra sus aspectos en un entorno de CI y tiene la seguridad de que los artefactos construidos se prueban y tejen correctamente. Si bien es cierto que puede escribir pruebas unitarias impulsadas por Spring, aún no tiene garantía de que el código implementado sea el que se probó si falla LTW.
Otra consideración es si aloja la aplicación en un entorno en el que puede supervisar directamente el éxito o el fracaso de un servidor/aplicación o si su aplicación se está implementando en un entorno donde no está bajo su supervisión [p.ej donde está alojado por un cliente]. Una vez más, esto señalaría el camino para compilar el tejido del tiempo.
Hace cinco años, estaba mucho más a favor del AOP configurado de Spring por la simple razón de que era más fácil trabajar con él y menos probable que masticara mi IDE. Sin embargo, a medida que el poder de cómputo y la memoria disponible han aumentado, esto se ha convertido en un problema mucho menor y CTW con el aspectj-maven-plugin se ha convertido en una mejor opción en mi entorno de trabajo basado en las razones que he descrito anteriormente.
Cuando existe alguna anotación en Spring pero también existe en Java, ¿qué debería usar? Java. La misma lógica se aplica a esta funcionalidad. La primavera es primavera. hoy aquí, mañana ya no. (Recuerde que las personas usaron Struts un tiempo antes de la primavera). AspectJ es la solución preferida a largo plazo. Durará más que la primavera. No descarto Spring, solo digo, por este aspecto ...: -; – inor