Эта статья переведена из блогаComparing Spring AOP and AspectJ
вводить
Сегодня доступно несколько библиотек АОП, и эти компоненты должны отвечать на ряд вопросов:
- Совместимо ли это с моим существующим приложением?
- Где я могу реализовать АОП?
- Быстро ли интегрируется в мое приложение?
- Сколько накладных расходов на производительность?
В этой статье мы сосредоточимся на ответах на эти вопросы и представим две самые популярные среды АОП для Java: Spring AOP и AspectJ.
Концепция АОП
Прежде чем мы начнем, давайте быстро и подробно рассмотрим терминологию и основные понятия:
- Аспект: стандартный код/функция, распределенная в нескольких местах приложения, часто отличающаяся от фактической бизнес-логики (например, управление транзакциями). Каждый аспект фокусируется на конкретной сквозной функции.
- Точка присоединения: это конкретная точка в выполнении программы, такая как выполнение метода, конструктор вызова конструктора или назначение поля и т. д.
- Советы: действия, предпринятые аспектом на точке соединения
- Pointcut: регулярное выражение, соответствующее точкам соединения. Всякий раз, когда какая-либо точка соединения соответствует pointcut, выполняется указанный совет, связанный с этим pointcut.
- Сплетение Сплетение: процесс связывания аспектов и целевых объектов для создания объекта уведомления.
Spring AOP and AspectJ
Теперь давайте обсудим Spring AOP и AspectJ по нескольким показателям, таким как возможности и цели, плетение, внутренняя структура, точки соединения и простота.
Capabilities and Goals
Короче говоря, Spring AOP и AspectJ преследуют разные цели.
Spring AOP стремится предоставить простую реализацию AOP через Spring IoC для решения наиболее распространенных проблем, с которыми сталкиваются программисты. Это не полное АОП-решение, его можно использовать только с управляемыми bean-компонентами контейнера Spring.
С другой стороны, AspectJ является наиболее примитивной технологией реализации АОП и предоставляет АОП-решение для игры с этим. AspectJ более надежный и сложный, чем Spring AOP. Стоит отметить, что AspectJ можно применять ко всем предметным объектам.
Weaving
Aspectj и Spring AOP используют разные методы плетения, что влияет на их производительность и простоту использования.
AspectJ использует три разных типа переплетения:
- Сплетение во время компиляции: компилятор AspectJ загружает как исходный код нашего аспекта, так и наше приложение, и генерирует файл сплетенного класса в качестве вывода.
- Плетение после компиляции: это известно как бинарное плетение. Он используется для объединения существующих файлов классов и JAR-файлов с нашим аспектом.
- Переплетение во время загрузки: это точно то же самое, что и предыдущее бинарное переплетение, за исключением того, что переплетение откладывается до тех пор, пока загрузчик классов не загрузит класс в JVM.
Для получения дополнительной информации об AspectJ см.head on over to this article.
AspectJ использует переплетение во время компиляции и загрузки класса, в то время как Spring AOP использует переплетение во время выполнения.
Операция ткачества, когда агент выполняет программу приложений с помощью целевого объекта, раздел компилятора (или CGLIB с помощью динамического прокси-агента JDK).
Internal Structure and Application
Spring AOP — это среда АОП на основе прокси. Это означает, что для реализации аспекта целевого объекта будет создан прокси-класс для целевого объекта. Этого можно достичь двумя способами:
- Динамический прокси-сервер JDK: предпочтительный метод для Spring AOP. Всякий раз, когда целевой объект реализует интерфейс, используется динамический прокси JDK.
- Прокси-сервер CGLIB: прокси-сервер CGLIB можно использовать, если целевой объект не реализует интерфейс.
Вы можете узнать больше о Spring AOP на официальном сайте.
AspectJ, с другой стороны, ничего не делает во время выполнения, классы и аспекты компилируются напрямую. Поэтому, в отличие от Spring AOP, он не требует никаких шаблонов проектирования. Чтобы вплести аспекты в код, он вводит собственное время компиляции, называемое компилятором AspectJ (ajc). Из него мы компилируем приложение, а затем запускаем его, предоставляя небольшую (
Joinpoints
В предыдущем разделе мы представили шаблон прокси на основе Spring AOP. Следовательно, он берет подкласс целевого класса и соответственно применяет сквозные аспекты. Но это также связано с ограничениями: мы не можем применять сквозные аспекты (или аспекты) к «конечным» классам, потому что их нельзя переопределить, что приводит к исключениям во время выполнения.
Точно так же его нельзя применять к статическим и окончательным методам. Поскольку их нельзя переопределить, к ним нельзя применить аспекты Spring. Поэтому Spring AOP из-за этих ограничений поддерживает только точки соединения, которые выполняют методы.
Тем не менее, AspectJ вплетает сквозные проблемы непосредственно в фактический код перед его запуском. В отличие от Spring AOP, ему не нужно наследовать от целевого объекта, поэтому также поддерживаются многие другие точки соединения. AspectJ поддерживает следующие точки соединения:
Также стоит отметить, что в Spring AOP аспекты не применяются к методам, вызываемым внутри одного класса. Очевидно, что когда мы вызываем метод в том же классе, мы не вызываем метод прокси, предоставленный Spring AOP. Если нам нужна эта функциональность, мы можем определить отдельный метод в разных bean-компонентах или использовать AspectJ.
Simplicity
Spring AOP, очевидно, проще, потому что он не вводит никакого дополнительного времени компиляции или переплетения во время компиляции. Он использует переплетение во время выполнения и, таким образом, легко интегрируется с нашим обычным процессом сборки. Несмотря на кажущуюся простоту, Spring AOP работает только с bean-компонентами, управляемыми Spring. .
Однако с AspectJ нам нужно подключить компилятор AJC, переупаковать все библиотеки (если только мы не переключимся на посткомпиляцию или переплетение во время загрузки). Этот метод более сложен, чем предыдущий, потому что он вводит инструменты Java AspectJ (включая компилятор (ajc), отладчик (ajdb), генератор документации (ajdoc), программу), которые нам нужно интегрировать с IDE или инструментами сборки обозревателя структуры ( jbrowser)).
Performance
Учитывая проблемы с производительностью, плетение во время компиляции намного быстрее, чем плетение во время выполнения. Spring AOP — это среда на основе прокси, поэтому при запуске приложения будет создан прокси-объект целевого класса. Кроме того, у каждого аспекта есть некоторые вызовы методов, которые могут повлиять на производительность.
В отличие от верхней части ASPECTJ Spring AOP, сплетена в передней части к коду выполнения приложения, без дополнительной работы.
По вышеуказанным причинам AspectJ был протестирован примерно в 8-35 раз быстрее, чем Spring AOP.benchmarks
В сравнении
Эта краткая таблица суммирует основные различия между Spring AOP и AspectJ:
Выберите правильный фреймворк
Если мы проанализируем все аргументы в этом разделе, то начнем понимать, что ни один фреймворк не может быть абсолютно лучше другого.
Словом, выбор во многом зависит от наших потребностей:
- Фреймворк: Если приложение не использует фреймворк Spring, то у нас нет другого выбора, кроме как отказаться от идеи использования Spring AOP, поскольку он не может управлять чем-либо за пределами контейнера Spring. Однако, если наше приложение полностью создано с использованием среды Spring, мы можем использовать Spring AOP, так как его легко изучить и применить.
- Гибкость. Учитывая ограниченную поддержку точек соединения, Spring AOP не является полным АОП-решением, но решает наиболее распространенные проблемы, с которыми сталкиваются программисты. AspectJ — лучший выбор, если мы хотим углубиться и максимально использовать АОП, а также получить поддержку от различных доступных точек соединения.
- Производительность: если мы используем ограниченные аспекты, разница в производительности невелика. Однако иногда приложения имеют десятки тысяч аспектов. В этом случае мы не хотим использовать переплетение во время выполнения, поэтому AspectJ — лучший выбор. Известно, что AspectJ в 8-35 раз быстрее, чем Spring AOP.
- Общее преимущество: две платформы полностью совместимы. Мы всегда можем воспользоваться преимуществами Spring AOP и по-прежнему использовать AspectJ для точек соединения, которые не поддерживаются первым.
Суммировать
В этой статье мы проанализировали ключевые аспекты Spring AOP и AspectJ. Мы сравнили гибкость двух подходов, АОП и АОП, и то, насколько хорошо они подходят для нашего приложения.