Spring AOP es una de las partes esenciales del marco de primavera. En la etapa más 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 marco.
El punto clave para comprender cómo funciona AOP en Spring es que cuando escribe un Aspecto con Spring, instrumentamos el marco con la creación de un proxy para sus objetos, con un JDKDynamicProxysi su bean implementa una interfaz o mediante CGLIB si su bean no implementa interfaz. Recuerde que debe tener cglib 2.2 en su ruta de clase si está utilizando Spring antes de la versión 3.2. A partir de Spring 3.2 es inútil porque se incluyó cglib 2.2 en el núcleo.
El marco en la creación del bean creará un proxy que envuelve sus objetos y agrega responsabilidades de preocupaciones transversales como la seguridad, la gestión de transacciones, el registro, etc.
La creación de proxy de esta manera se aplicará a partir de una expresión de corte de punto que instrumente el marco para decidir qué beans y métodos se crearán como proxies. El consejo será la mayor responsabilidad que su código. Recuerde que en este proceso, el corte de puntos captura solo métodos públicos que no se declaran como finales.
Ahora, mientras que en Spring AOP el tejido de Aspects será realizado por el contenedor al inicio del contenedor, en AspectJ debe realizar esto con una compilación posterior de su código a través de la modificación de bytecode. 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 Spring AOP no puede usar todo el poder de AOP porque la implementación se realiza a través de servidores proxy y no a través de la modificación de su código.
Como en AspectJ, puede usar el tejido de tiempo de carga en SpringAOP. Puede beneficiarse de esta característica en primavera que se implementa con un agente y configuraciones especiales, @EnabledLoadWeavingo en XML. Puede usar el espacio de nombres como ejemplo. Sin embargo, en Spring AOP no puedes interceptar todos los casos. Por ejemplo, el newcomando no es compatible con Spring AOP.
Sin embargo, en Spring AOP puede beneficiarse del uso de AspectJ mediante el uso del aspectofmétodo de fábrica 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 beans. Otro punto de comparación es la depuración y la previsibilidad del comportamiento del código. Con spring AOP, el trabajo se realiza todo desde el compilador de Java y los aspectos son una forma genial de crear proxy para su Spring bean. En AspectJ, si modifica el código, necesita más compilación y comprender dónde se tejen sus aspectos podría ser difícil. Incluso cerrar el tejido en primavera es más simple: con Spring elimina el aspecto de su configuración, reinicia y funciona. ¡En AspectJ debes recompilar el código!
En el 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 tiempo de carga de un aspecto que cambia el comportamiento de su nuevo operador.
Espero que esta panorámica de AspectJ y Spring AOP te ayude a comprender la diferencia de las dos pociones