Весенний AOP против AspectJ

StackOverflow https://stackoverflow.com/questions/1606559

Вопрос

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

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

Это было полезно?

Решение

Весна-Плюсы AOP

  • Это проще в использовании, чем AspectJ, так как вам не нужно использовать LTW (плетение во время загрузки) или компилятор AspectJ.

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

Минусы Spring-AOP

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

Аспекты Плюсов

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

Аспектные Минусы

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

Другие советы

Помимо того, что говорили другие - просто перефразируя, есть два основных различия :

<Ол>
  • Один из них связан с типом плетения.
  • Еще одно определение точки соединения.

    • Spring-AOP: время выполнения с использованием прокси с использованием концепции динамического прокси, если интерфейс существует, или библиотеки cglib, если предусмотрена прямая реализация.

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

    Ткачество времени компиляции может предложить преимущества производительности (в некоторых случаях), а также определение точки соединения в Spring-aop ограничено только определением метода, что не относится к AspectJ.

    Руководство пользователя Spring даст много полезного информации, прямо изо рта лошади.

    Глава 6.4 - Выбор декларации AOP стиль использования для вас мертв, поскольку в нем обсуждаются плюсы и минусы обоих.

    Абзац 6.1. 2 - Spring AOP Возможности и цели & amp; главы 6.2 - поддержка @Aspect и 6.8 - Использование AspectJ с приложениями Spring должно быть особенно интересно.

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

    См. тесты .

    Spring AOP является одной из важнейших частей spring Framework.На самом базовом этапе spring framework основан на IoC и AOP.В официальном курсе Spring есть слайд, на котором написано:

    AOP является одной из наиболее важных частей фреймворка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Это Статья также есть хорошее объяснение по этой теме.

    Spring AOP и AspectJ преследуют разные цели.

    Spring AOP стремится обеспечить простую реализацию AOP в Spring IoC для решения наиболее распространенных проблем, с которыми сталкиваются программисты.

    С другой стороны, AspectJ - это оригинальная технология AOP, целью которой является предоставление комплексного решения AOP.

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top