Вибір стилю АОП

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