У меня сложилось впечатление, что Spring AOP лучше всего использовать для конкретных задач приложения, таких как безопасность, ведение журнала, транзакции и т. Д., Поскольку он использует пользовательские аннотации Java5 в качестве основы. Однако AspectJ кажется более дружелюбным с точки зрения шаблонов проектирования.
Может ли кто-нибудь выделить различные плюсы и минусы использования Spring AOP и AspectJ в приложении Spring?
Плюсы Spring-AOP
Его проще использовать, чем AspectJ, поскольку вам не нужно использовать LTW (ткачество во время загрузки) или компилятор AspectJ.
Он использует шаблон прокси и шаблон декоратора.
Spring-AOP Минусы
AspectJ Плюсы
AspectJ Минусы
If you need to advise objects not managed by the Spring container (such as domain objects typically), then you will need to use AspectJ.
- person HDave; 13.08.2013
Дополнительное примечание: Если важна производительность при высокой нагрузке, вам понадобится AspectJ, который в 9–35 раз быстрее, чем Spring AOP. 10 нс против 355 нс может показаться не таким уж большим, но я видел людей, использующих МНОГО аспектов. 10 тысяч аспектов. В этих случаях ваш запрос может затронуть тысячи аспектов. В этом случае вы добавляете мс к этому запросу.
Помимо того, что заявили другие - просто перефразируя, there are two major differences:
Spring-AOP: переплетение среды выполнения через прокси с использованием концепции dynamic proxy if interface exists or cglib library if direct implementation provided.
AspectJ: переплетение времени компиляции через AspectJ Java Tools(ajc compiler), если доступен источник, или переплетение после компиляции (с использованием скомпилированных файлов). Кроме того, можно включить изменение времени загрузки с помощью Spring - для этого требуется файл определения aspectj и он обеспечивает гибкость.
Ткачество времени компиляции может предложить преимущества производительности (в некоторых случаях), а также joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.
Руководство пользователя Spring предоставит много информации, прямо изо рта лошади.
Глава 6.4 - Выбор стиля объявления AOP для использования неуместен для вас, поскольку в нем обсуждаются плюсы и минусы обоих.
Абзац 6.1.2 - Spring Возможности и цели АОП и главы 6.2 - поддержка @Aspect и 6.8. Использование AspectJ с приложениями Spring должно быть особенно интересным.
Пружинный АОП - одна из важнейших частей пружинного каркаса. На самом базовом этапе Spring framework основан на IoC и AOP. В официальном курсе Spring есть слайд, на котором говорится:
АОП - одна из самых важных частей фреймворка.
Ключевым моментом для понимания того, как работает АОП в Spring, является то, что когда вы пишете аспект с помощью Spring, мы инструментируем фреймворк построением прокси для ваших объектов с помощью JDKDynamicProxy, если ваш компонент реализует интерфейс, или через CGLIB, если ваш компонент не реализует любой интерфейс. Помните, что у вас должен быть cglib 2.2 в вашем пути к классу, если вы используете Spring до версии 3.2. Начиная с Spring 3.2 он бесполезен, потому что cglib 2.2 был включен в ядро.
Фреймворк при создании bean-компонента создаст прокси, который обертывает ваши объекты и добавляет сквозные обязанности, такие как безопасность, управление транзакциями, ведение журнала и т. Д.
Создание прокси таким образом будет применяться, начиная с выражения pointcut, которое инструментирует структуру, чтобы решить, какие bean-компоненты и методы будут созданы в качестве прокси. За советом будет больше ответственности, чем за ваш код. Помните, что в этом процессе pointcut захватывает только общедоступные методы, которые не объявлены как final.
Теперь, в то время как в Spring AOP создание аспектов будет выполняться контейнером при запуске контейнера, в AspectJ вы должны выполнить это с последующей компиляцией вашего кода посредством модификации байт-кода. По этой причине, на мой взгляд, подход Spring проще и управляемее, чем AspectJ.
С другой стороны, с Spring AOP вы не можете использовать всю мощь АОП, потому что реализация осуществляется через прокси, а не путем модификации вашего кода.
Как и в AspectJ, в SpringAOP можно использовать ткачество во время загрузки. Вы можете воспользоваться этой функцией, которая будет реализована в Spring с помощью агента и специальных конфигураций, @EnabledLoadWeaving или в XML. Вы можете использовать пространство имен в качестве примера. Однако в Spring AOP вы не можете перехватить все случаи. Например, команда new не поддерживается в Spring AOP.
Однако в Spring AOP вы можете извлечь выгоду из использования AspectJ за счет использования фабричного метода aspectof в компоненте конфигурации Spring.
По той причине, что Spring AOP - это в основном прокси, созданный из контейнера, поэтому вы можете использовать AOP только для Spring beans. В то время как с AspectJ вы можете использовать аспект во всех ваших bean-компонентах. Еще один момент для сравнения - отладка и предсказуемость поведения кода. В Spring AOP все задания выполняются компилятором Java, и аспекты - это очень крутой способ создания прокси для вашего компонента Spring. В AspectJ, если вы изменяете код, вам нужно больше компилировать, и понять, где сплетены ваши аспекты, может быть сложно. Даже выключение плетения весной проще: с пружиной вы удаляете аспект из своей конфигурации, перезапускаете, и он работает. В AspectJ вы должны перекомпилировать код!
В ткачестве во время загрузки AspectJ более гибок, чем Spring, потому что Spring не поддерживает все параметры AspectJ. Но, на мой взгляд, если вы хотите изменить процесс создания bean-компонента, лучший способ - управлять пользовательским входом в систему на фабрике, а не с изменением во время загрузки аспекта, который изменяет поведение вашего нового оператора.
Я надеюсь, что этот обзор AspectJ и Spring AOP поможет вам понять разницу между двумя зелиями.
В этой статье также есть хорошее объяснение по теме.
Spring AOP и AspectJ преследуют разные цели.
Spring AOP стремится предоставить простую реализацию АОП в Spring IoC для решения наиболее распространенных проблем, с которыми сталкиваются программисты.
С другой стороны, AspectJ - это оригинальная технология АОП, целью которой является предоставление полного решения АОП.
Важно учитывать, будут ли ваши аспекты критически важными и где будет разворачиваться ваш код. Spring AOP будет означать, что вы полагаетесь на ткачество во время загрузки. Это может не сработать, и по моему опыту это означает, что могут существовать зарегистрированные ошибки, но это не помешает запуску приложения без кода аспекта [Я бы добавил предостережение, что его можно настроить таким образом, чтобы это это не так; но лично мне об этом не известно]. Плетение во время компиляции избегает этого.
Кроме того, если вы используете AspectJ в сочетании с подключаемым модулем Aspectj-maven-plugin, вы можете запускать модульные тесты для ваших аспектов в среде CI и быть уверенным, что построенные артефакты протестированы и правильно сплетены. Хотя вы, безусловно, можете писать модульные тесты, управляемые Spring, у вас все еще нет гарантии, что развернутый код будет тем, который был протестирован в случае сбоя LTW.
Еще одно соображение заключается в том, размещаете ли вы приложение в среде, где вы можете напрямую отслеживать успешность или неудачу запуска сервера / приложения, или ваше приложение развертывается в среде, где оно не находится под вашим контролем [например, где он размещен у клиента]. Опять же, это укажет путь к компиляции ткачества времени.
Пять лет назад я был более склонен к настройке АОП Spring по той простой причине, что с ним было легче работать и меньше шансов проглотить мою IDE. Однако по мере увеличения вычислительной мощности и доступной памяти это стало гораздо менее серьезной проблемой, и CTW с аспектомj-maven-plugin стал лучшим выбором в моей рабочей среде по причинам, которые я изложил выше.
По сравнению с АОП, AspectJ не нужно улучшать целевой класс во время компиляции. Вместо этого он генерирует прокси-класс для целевого класса во время выполнения, который либо реализует тот же интерфейс, что и целевой класс, либо является подклассом целевого класса.
Таким образом, экземпляр прокси-класса может быть используется как экземпляр целевого класса. В целом, среда АОП, улучшенная во время компиляции, более выгодна с точки зрения производительности, потому что среда АОП, расширенная во время выполнения, требует динамических улучшений при каждом запуске.
