Spring AOP vs AspectJ

Question

У меня создается впечатление, что Spring AOP лучше всего использовать для конкретных задач, таких как безопасность, протоколирование, транзакции и т. Д., Так как использует пользовательские аннотации Java5 в качестве фреймворка. Тем не менее, AspectJ, похоже, более дружелюбен к дизайну.

Может ли кто-нибудь выделить различные плюсы и минусы использования Spring AOP против AspectJ в приложении Spring?

Answer 1

весна-АОП Pros

• Это проще в использовании, чем AspectJ, так как вы не должны использовать LTW (load-time weaving) или компилятор AspectJ.

• Он использует шаблон прокси и декоратора шаблон

весна-АОП Cons

• Это прокси на основе АОП, так что в основном вы можете использовать только метод-исполнения joinpoints.
• Аспекты не применяются при вызове другого метода в пределах одного класса.
• Накладные расходы могут быть небольшими.
• Spring-АОП не может добавить аспект к чему-либо, что не создается на весеннем заводе

AspectJ Pros

• Это поддерживает все joinpoints. Это означает, что вы можете сделать что угодно.
• Накладные расходы меньше, чем у Spring AOP.

AspectJ Против

• Будьте осторожны. Проверьте, не укладываются ли ваши аспекты только в том, что вы хотели сплести.
• требуется дополнительный процесс сборки с AspectJ компилятором или должен установить LTW (время загрузки ткачество)

Answer 2

The spring user manual даст много информации, из первоисточника.

Глава 6.4 - Choosing which AOP declaration style to use умерла для вас, так как она обсуждает плюсы и минусы обоих.

Отметим, что параграф 6.1.2 - Spring AOP Capabilites and goals & главами 6.2 - @Aspect support и 6.8 - Using AspectJ with Spring applications должно быть особенно интересно.

Answer 3

Помимо того, что другие заявили - просто перефразировать, there are two major differences:

1. Один из них связан с типом плетения.
2. Другое определение точки соединения.

весна-АОП: времени выполнения ткачество через прокси-сервер, используя концепцию dynamic proxy if interface exists or cglib library if direct implementation provided.

AspectJ: времени компиляции ткачества AspectJ Java Tools(ajc compiler), если источник доступен или после компиляции ткачества (с использованием скомпилированных файлов). Кроме того, можно включить загрузку времени с пружиной - для этого нужен файл определения aspectj и предлагает гибкость.

Compile время ткачества может предложить преимущества производительности (в некоторых случаях), а также joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.

Answer 4

дополнительное примечание: Если производительность при высокой нагрузке важно, вы хотите AspectJ, который 9-35x быстрее Spring AOP. 10ns против 355ns может показаться не очень похожим, но я видел людей, использующих LOTS of Aspects. 10K стоит аспектов. В этих случаях ваш запрос может затронуть тысячи аспектов. В этом случае вы добавляете ms к этому запросу.

См. benchmarks.

Answer 5

Spring AOP - одна из важнейших частей пружинного каркаса. На самом базовом этапе весенний каркас основан на IoC и АОП. В официальном курсе весны есть слайд, в котором говорится:

АОП является одной из важнейших частей каркаса.

Ключевой момент для понимания того, как AOP в Spring работает в том, что когда вы пишете аспект с весной мы инструмент рамка с построением прокси для ваших объектов, с JDKDynamicProxy, если ваш компонент реализует интерфейс или через CGLIB если ваш компонент не реализует никакого интерфейса. Помните, что вы должны иметь cglib 2.2 в своем классе, если используете Spring до версии 3.2. Начиная с весны 3.2 это бесполезно, потому что cglib 2.2 был включен в ядро.

Рамка при создании бина создаст прокси-сервер, который будет обертывать ваши объекты и добавляет сквозные функции, такие как безопасность, управление транзакциями, ведение журнала и т. Д.

Создание прокси таким образом будет применяться, начиная с выражения pointcut, которое позволяет фреймворку определить, какие бобы и методы будут созданы как прокси. Совет будет больше ответственности, чем за ваш код. Помните, что в этом процессе pointcut захватывает только общедоступные методы, которые не объявляются окончательными.

Теперь, находясь в Spring AOP, плетение Аспектов будет выполняться контейнером при запуске контейнера, в AspectJ вы должны выполнить это с последующей компиляцией своего кода с помощью модификации байт-кода. По этой причине, на мой взгляд, подход Spring более прост и управляем, чем AspectJ.

С другой стороны, с Spring AOP вы не можете использовать всю мощность АОП, потому что реализация выполняется через прокси, а не с помощью модификации вашего кода.

Как и в AspectJ, вы можете использовать ткачество с нагрузкой в ​​SpringAOP. Вы можете воспользоваться этой функцией весной, реализованной с помощью агента и специальных конфигураций, @EnabledLoadWeaving или в формате XML. Вы можете использовать имя-пространство в качестве примера. Однако в Spring AOP вы не можете перехватить все случаи. Например, команда new не поддерживается в Spring AOP.

Однако весной AOP вы можете воспользоваться использованием AspectJ с использованием заводского метода aspectof в компоненте конфигурации пружины.

По той причине, что Spring AOP является в основном прокси-сервером, созданным из контейнера, поэтому вы можете использовать АОП только для весенних бобах. В то время как с AspectJ вы можете использовать этот аспект во всех своих компонентах. Еще одна точка сравнения - отладка и предсказуемость поведения кода. С Spring AOP задание готовится из компилятора Java, а аспекты - очень классный способ создания прокси-сервера для вашего Spring-компонента. В AspectJ, если вы изменяете код, вам нужно больше компиляции и понять, где ваши аспекты сплетены, может быть сложно. Даже закрытие ткачества весной проще: с пружиной вы удаляете аспект из своей конфигурации, перезапускайте и работаете. В AspectJ вы должны перекомпилировать код!

В процессе загрузки, AspectJ более гибкий, чем Spring, потому что Spring не поддерживает все опции AspectJ. Но, на мой взгляд, если вы хотите изменить процесс создания компонента, лучшим способом является управление пользовательским входом на заводе, а не с загрузкой времени, связанным с аспектом, который изменяет поведение вашего нового оператора.

Я надеюсь, что это панорамное из AspectJ и Spring AOP поможет вам понять разницу между двумя зелий

Answer 6

Это важно учитывать, будут ли ваши аспекты быть критически важными и где ваш код развертываются. Spring AOP будет означать, что вы полагаетесь на ткачество во время загрузки. Это может не спеть и, по моему опыту, означало, что зарегистрированные ошибки могут существовать, но не будут препятствовать запуску приложения без кода аспекта. [Я хотел бы добавить предостережение о том, что его можно настроить таким образом, чтобы это не было дело; но я лично не знаю об этом]. Компиляция во времени избегает этого.

Кроме того, если вы используете AspectJ в сочетании с плагином aspectj-maven, вы можете запускать модульные тесты против ваших аспектов в среде CI и уверенность в том, что встроенные артефакты были протестированы и правильно сплетены. Хотя вы, безусловно, можете записывать модульные тесты Spring, у вас все еще нет гарантии, что развернутый код будет таким, который был протестирован при сбое LTW.

Еще одно соображение заключается в том, размещаете ли вы приложение в среде, где вы можете напрямую отслеживать успех или неудачу запуска сервера/приложения или развертывание вашего приложения в среде, где она не находится под вашим контролем [например где он размещен клиентом]. Опять же, это указывает на способ компиляции времени.

Пять лет назад я был гораздо более настроен на поддержку Spring AOP по той простой причине, что было легче работать и с меньшей вероятностью пережевывать мою IDE. Однако, поскольку вычислительная мощность и доступная память увеличились, это стало намного менее серьезной проблемой, и CTW с плагином aspectj-maven стал лучшим выбором в моей рабочей среде, исходя из причин, которые я изложил выше.