Выбор стиля АОП

Если решено, что использование аспекта является лучшим подходом для выполнения данного задания, как понять,что использовать - Spring AOP или AspectJ, а также, что выбрать - стиль языка (кода) Aspect, стиль аннотаций @AspectJ или стиль Spring XML? На этот выбор влияет ряд факторов, включая требования к приложению, средства разработки и знакомство команды с АОП.

Spring AOP или полнофункциональный AspectJ?

Используйте самое простое решение, которое будет работать. Spring AOP более прост в использовании, чем полнофункциональный AspectJ, поскольку отсутствует необходимость внедрять компилятор/инструмент связывания из AspectJ в процессы разработки и сборки. Если вам нужно лишь управлять выполнением операций над бинами Spring, то Spring AOP - правильный выбор. Если вам нужно снабдить советами объекты, которые не находятся под управлением контейнера Spring (например, объекты предметной области, как правило), то нужно использовать AspectJ. Также необходимо использовать AspectJ, если нужно снабдить советами точки соединения, отличные от простых выполнений методов (например, точки соединения field get или set и так далее).

Если вы используете AspectJ, то можете выбирать между синтаксисом языка AspectJ (также известным как "стиль кода") и стилем аннотаций @AspectJ. Очевидно, что если вы не используете Java 5+, то выбор уже сделан за вас: Используйте стиль кода. Если аспекты играют большую роль в вашем проекте, и вы можете использовать плагин AspectJ Development Tools (AJDT) для Eclipse, синтаксис языка AspectJ является предпочтительным вариантом. Он чище и проще, поскольку этот язык был специально разработан для написания аспектов. Если вы не используете Eclipse или у вас всего несколько аспектов, которые не играют большой роли в приложении, то можете рассмотреть возможность использования стиля @AspectJ, придерживаясь обычной компиляции Java в вашей IDE, и добавив этап связывания аспектов в скрипт сборки.

@AspectJ или XML для Spring AOP?

Если вы решили использовать Spring AOP, то можете выбрать между стилем @AspectJ или XML. Необходимо учитывать различные компромиссы.

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

Стиль XML имеет два недостатка. Во-первых, он не полностью инкапсулирует реализацию задачи, которую он решает, в одном месте. Принцип "не повторяйся" (Don’t repeat yourself/DRY) гласит, что каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы При использовании стиля XML знания о том, как реализуется задача, распределяются между объявлением класса базового бина и XML в конфигурационном файле. Если вы используете стиль @AspectJ, то эта информация заключена в одном модуле: аспекте. Во-вторых, стиль XML немного более ограничен, чем стиль @AspectJ, в плане выразительности: Поддерживается только модель создания одиночных экземпляров аспекта, и невозможно объединить именованные срезы, объявленные в XML. Например, при использовании стиля @AspectJ можно написать что-то вроде:

@Pointcut("execution(* get*())")
public void propertyAccess() {}
@Pointcut("execution(org.xyz.Account+ *(..))")
public void operationReturningAnAccount() {}
@Pointcut("propertyAccess() && operationReturningAnAccount()")
public void accountPropertyAccess() {}

@Pointcut("execution(* get*())")
fun propertyAccess() {}
@Pointcut("execution(org.xyz.Account+ *(..))")
fun operationReturningAnAccount() {}
@Pointcut("propertyAccess() && operationReturningAnAccount()")
fun accountPropertyAccess() {}

В стиле XML можно объявить первые два среза:

<aop:pointcut id="propertyAccess"
        expression="execution(* get*())"/>
<aop:pointcut id="operationReturningAnAccount"
        expression="execution(org.xyz.Account+ *(..))"/>

Недостатком XML-подхода является то, что нельзя определить срез accountPropertyAccess, комбинируя эти определения.

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

Смешанное использование типов аспектов

Вполне допустимо смешанное использование в одной конфигурации аспектов, написанных в стиле @AspectJ с использованием инструментальных средств автопроксирования, определенных схемой аспектов <aop:aspect>, объявленных советников <aop:advisor> и даже прокси и перехватчиков, написанных в других стилях. Все они реализуются с помощью одного и того же базового механизма поддержки и могут сосуществовать без каких-либо проблем.