Spring AOP является одной из основных частей каркаса пружины. На самом базовом этапе основа пружины основана на IoC и AOP. В официальном курсе Spring есть слайд, на котором написано:
АОП является одной из наиболее важных частей структуры.
Ключевым моментом для понимания того, как работает AOP в Spring, является то, что когда вы пишете Aspect с помощью Spring, мы инструментируем платформу с созданием прокси для ваших объектов с помощью, JDKDynamicProxyесли ваш бин реализует интерфейс, или через CGLIB, если ваш бин не реализует какие-либо интерфейс. Помните, что вы должны иметь cglib 2.2 в вашем пути к классам, если вы используете Spring до версии 3.2. Начиная с Spring 3.2 это бесполезно, потому что в ядро был включен cglib 2.2.
Инфраструктура при создании компонента создаст прокси-сервер, который обернет ваши объекты и добавит сквозные задачи, такие как безопасность, управление транзакциями, ведение журнала и так далее.
Таким образом, создание прокси будет применяться, начиная с выражения pointcut, которое инструментирует платформу, чтобы решить, какие компоненты и методы будут созданы как прокси. Совет будет более ответственным, чем за ваш код. Помните, что в этом процессе pointcut захватывает только открытые методы, которые не объявлены как final.
Теперь, в то время как в Spring AOP ткачество аспектов будет выполняться контейнером при запуске контейнера, в AspectJ вы должны выполнить это после посткомпиляции кода с помощью модификации байт-кода. По этой причине, на мой взгляд, подход Spring проще и более управляем, чем AspectJ.
С другой стороны, в Spring AOP вы не можете использовать всю мощь AOP, потому что реализация осуществляется через прокси, а не через модификацию вашего кода.
Как и в AspectJ, вы можете использовать время загрузки в SpringAOP. Вы можете извлечь выгоду из этой функции весной, реализованной с помощью агента и специальных конфигураций, @EnabledLoadWeavingили в XML. Вы можете использовать пространство имен в качестве примера. Однако в Spring AOP вы не можете перехватить все случаи. Например, newкоманда не поддерживается в Spring AOP.
Однако в Spring AOP вы можете извлечь выгоду из использования AspectJ через использование aspectofфабричного метода в компоненте конфигурации Spring.
По той причине, что Spring AOP - это в основном прокси, созданный из контейнера, поэтому вы можете использовать AOP только для Spring Bean. В то время как с AspectJ вы можете использовать аспект во всех ваших бобах. Другая точка сравнения - отладка и предсказуемость поведения кода. В Spring AOP все задание выполняется с помощью компилятора Java, а аспекты являются очень хорошим способом создания прокси для вашего компонента Spring. В AspectJ, если вы модифицируете код, вам нужно больше компилировать, и понять, где сплетены ваши аспекты, может быть сложно. Даже выключить ткачество весной проще: с помощью пружины вы удаляете аспект из вашей конфигурации, перезапускаете, и это работает. В AspectJ вы должны перекомпилировать код!
В ткачестве во время загрузки AspectJ более гибок, чем Spring, потому что Spring не поддерживает все опции AspectJ. Но, на мой взгляд, если вы хотите изменить процесс создания bean-компонента, лучшим способом будет управление настраиваемым входом в систему на фабрике, а не с переплетением во время загрузки аспекта, который изменяет поведение вашего нового оператора.
Я надеюсь, что этот обзор AspectJ и Spring AOP поможет вам понять разницу двух зелий