Якщо вирішено, що використання аспекту є найкращим підходом для виконання цього завдання, як зрозуміти, що використовувати - 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 можна написати щось на кшталт:

Java
@Pointcut("execution(* get*())")
public void propertyAccess() {}
@Pointcut("execution(org.xyz.Account+ *(..))")
public void operationReturningAnAccount() {}
@Pointcut("propertyAccess() && operationReturningAnAccount()")
public void accountPropertyAccess() {}
Kotlin
@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> ; і навіть проксі та перехоплювачів, написаних в інших стилях. Всі вони реалізуються за допомогою того самого базового механізму підтримки і можуть співіснувати без будь-яких проблем.