У меня создается впечатление, что Spring AOP лучше всего использовать для конкретных приложений, таких как безопасность, протоколирование, транзакции и т.д., поскольку он использует пользовательские аннотации Java5 в качестве фреймворка. Тем не менее, AspectJ, похоже, более дружелюбен к дизайну.
Можно ли выделить различные плюсы и минусы использования Spring AOP vs AspectJ в приложении Spring?
Весна-АОП Плюсы
Его проще использовать, чем AspectJ, так как вам не нужно использовать LTW (ткачество во время загрузки) или компилятор AspectJ.
Он использует шаблон прокси и шаблон Decorator
Spring-AOP Cons
AspectJ Pros
AspectJ Cons
Кроме того, что заявили другие, просто перефразируйте 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.
Весеннее руководство пользователя даст много информации прямо из устья лошади.
Глава 6.4 - Выбор стиля рекламы AOP для вас мертв, поскольку он обсуждает плюсы и минусы обоих.
Параграф 6.1.2 - Capabilites Spring и цели и главы 6.2 - поддержка @Aspect и 6.8 - Использование AspectJ с приложениями Spring должно быть особенно интересно.
Дополнительная заметка: Если производительность при высокой нагрузке важна, вам понадобится AspectJ, который на 9-35 раз быстрее, чем Spring AOP. 10ns против 355ns может показаться не очень похожим, но я видел людей, использующих LOTS of Aspects. 10 тыс. Аспектов. В этих случаях ваш запрос может затронуть тысячи аспектов. В этом случае вы добавляете ms к этому запросу.
См. тесты.
Spring АОП является одной из существенных частей структуры spring. На самом базовом этапе структура spring основана на IoC и AOP. В официальном курсе spring есть слайд, в котором говорится:
AOP является одной из наиболее важных частей структуры.
Ключевым моментом для понимания того, как работает АОП в spring, является то, что при написании Aspect с spring мы обрабатываем фреймворк с созданием прокси для ваших объектов с помощью JDKDynamicProxy, если ваш bean реализует интерфейс или через CGLIB, если ваш bean не реализует никакого интерфейса. Помните, что вы должны иметь cglib 2.2 в своем классе, если вы используете spring до версии 3.2. Начиная с spring 3.2, это бесполезно, поскольку cglib 2.2 был включен в ядро.
Структура при создании bean создаст прокси-сервер, который обертывает ваши объекты и добавляет проблемы с перекрестными ограничениями, такие как безопасность, управление транзакциями, ведение журнала и т.д.
Создание прокси-сервера таким образом будет применяться, начиная с выражения pointcut, которое определяет структуру, определяющую, что beans и методы будут созданы как прокси. Совет будет больше ответственности, чем за ваш код. Помните, что в этом процессе pointcut захватывает только общедоступные методы, которые не объявляются окончательными.
Теперь, в то время как в spring AOP плетение Аспектов будет выполняться контейнером при запуске контейнера, в AspectJ вы должны выполнить это с посткомпиляцией вашего кода с помощью модификации байт-кода. По этой причине, на мой взгляд, подход spring проще и удобнее, чем AspectJ.
С другой стороны, с помощью spring AOP вы не можете использовать всю мощность AOP, потому что реализация выполняется через прокси, а не с помощью модификации вашего кода.
Как и в AspectJ, вы можете использовать временное сотканье в SpringAOP. Вы можете воспользоваться этой функцией в spring, реализованной с агентом и специальными конфигурациями, @EnabledLoadWeaving или в XML. Вы можете использовать имя-пространство в качестве примера. Однако в spring АОП вы не можете перехватить все случаи. Например, команда new не поддерживается в spring AOP.
Однако в spring AOP вы можете воспользоваться использованием AspectJ с помощью метода aspectof factory в конфигурации spring bean.
По той причине, что spring AOP - это в основном прокси, созданный из контейнера, поэтому вы можете использовать AOP только для spring beans. Хотя с AspectJ вы можете использовать аспект во всех своих beans. Еще одна точка сравнения - отладка и предсказуемость поведения кода. С помощью spring AOP задание выполняется из Java-компилятора, а аспекты - очень классный способ создания прокси-сервера для вашего spring bean. В AspectJ, если вы изменяете код, вам нужно больше компиляции и понять, где ваши аспекты сплетены, может быть сложно. Даже закрытие плетения в spring проще: с помощью spring вы удаляете аспект из своей конфигурации, перезапускаете и работаете. В AspectJ вы должны перекомпилировать код!
При загрузке во времени, AspectJ более гибкий, чем spring, потому что spring не поддерживает все опции AspectJ. Но, на мой взгляд, если вы хотите изменить процесс создания bean, лучшим способом является управление пользовательским входом в factory, а не с перекосом времени загрузки аспекта, который изменяет поведение вашего нового оператора.
Я надеюсь, что этот панорамный вид AspectJ и spring AOP поможет вам разобраться в различии двух зелий
Важно учитывать, будут ли ваши аспекты критически важными и где будет развертываться ваш код. Spring AOP будет означать, что вы полагаетесь на ткачество во время загрузки. Это может не спеть и, по моему опыту, означало, что зарегистрированные ошибки могут существовать, но не будут препятствовать запуску приложения без аспектного кода. [Я бы добавил, что можно настроить его таким образом, чтобы это не было дело; но я лично не знаю об этом]. Компиляция во времени избегает этого.
Кроме того, если вы используете AspectJ в сочетании с плагином aspectj-maven, вы можете запускать модульные тесты против ваших аспектов в среде CI и иметь уверенность в том, что встроенные артефакты тестируются и правильно сотканы. Хотя вы, безусловно, можете записывать модульные тесты Spring, у вас все еще нет гарантии, что развернутый код будет таким, который был протестирован при сбое LTW.
Еще одно соображение заключается в том, размещаете ли вы приложение в среде, где вы можете напрямую отслеживать успех или неудачу запуска сервера/приложения или развертывать ли приложение в среде, где он не находится под вашим контролем [например, где это размещается клиентом]. Опять же, это указывает на способ компиляции времени.
Пять лет назад я был гораздо больше сторонником Spring, настроенного AOP по той простой причине, что было легче работать с и реже, чтобы пережевывать мою среду IDE. Однако, поскольку вычислительная мощность и доступная память увеличились, это стало намного менее серьезной проблемой, и CTW с плагином aspectj-maven стал лучшим выбором в моей рабочей среде, исходя из причин, которые я изложил выше.
Вы можете использовать интеграцию Springs с AspectJ для настройки объектов, которые были созданы вне элемента управления контейнера IoC.
Эта статья также имеет хорошее объяснение по теме.
Spring AOP и AspectJ имеют разные цели.
Spring AOP стремится обеспечить простую реализацию AOP в Spring IoC для решения наиболее распространенных проблем, с которыми сталкиваются программисты.
С другой стороны, AspectJ является оригинальной технологией AOP, которая направлена на предоставление полного решения AOP.
По сравнению с AOP AspectJ не нуждается в улучшении целевого класса во время компиляции. Вместо этого он генерирует прокси-класс для целевого класса во время выполнения, который либо реализует тот же интерфейс, что и целевой класс, либо является подклассом целевого класса.
Таким образом, экземпляр прокси-класса может использоваться как экземпляр целевого класса. В целом, расширенная структура AOP во время компиляции является более выгодной по производительности, поскольку расширенная среда AOP во время выполнения требует динамических улучшений при каждом запуске.