Choosing which AOP Declaration Style to Use

일단 특정 요구 사항을 구현하는 데 aspect가 최선의 접근 방식이라고 결정했다면, Spring AOP와 AspectJ 중에서 무엇을 사용할지, 그리고 Aspect language (code) style, @AspectJ 어노테이션 style, Spring XML style 중에서 무엇을 사용할지를 어떻게 결정해야 할까요? 이러한 결정은 애플리케이션 요구 사항, 개발 도구, 팀의 AOP 숙련도 등 여러 요인의 영향을 받습니다.

Spring AOP or Full AspectJ?

동작할 수 있는 가장 단순한 것을 사용하십시오. Spring AOP는 full AspectJ를 사용하는 것보다 더 단순합니다. 개발과 빌드 프로세스에 AspectJ 컴파일러 / 위버를 도입해야 할 필요가 없기 때문입니다. Spring 빈에서 연산 실행을 어드바이스하기만 하면 되는 경우 Spring AOP가 올바른 선택입니다.

Spring 컨테이너에서 관리하지 않는 객체들(예를 들어, 일반적으로 도메인 객체들)을 어드바이스해야 한다면 AspectJ를 사용해야 합니다. 또한 단순한 메서드 실행 이외의 조인 포인트(예를 들어, 필드 get 또는 set 조인 포인트 등)를 어드바이스하고자 할 경우에도 AspectJ를 사용해야 합니다.

AspectJ를 사용할 때는 AspectJ language syntax("code style"로도 알려져 있음)와 @AspectJ 어노테이션 style 중에서 선택할 수 있습니다. aspects가 설계에서 큰 역할을 하고 Eclipse용 AspectJ Development Tools (AJDT) 플러그인을 사용할 수 있다면, AspectJ language syntax가 선호되는 옵션입니다.

이 언어는 aspects를 작성하기 위해 의도적으로 설계되었기 때문에 더 깔끔하고 단순합니다. Eclipse를 사용하지 않거나 애플리케이션에서 큰 역할을 하지 않는 소수의 aspects만 있다면, @AspectJ style을 사용하고 IDE에서 일반적인 Java 컴파일을 유지한 채 빌드 스크립트에 aspect 위빙 단계를 추가하는 방식을 고려해 볼 수 있습니다.

@AspectJ or XML for Spring AOP?

Spring AOP를 사용하기로 선택했다면, @AspectJ style과 XML style 중에서 선택할 수 있습니다. 여러 가지 트레이드오프를 고려해야 합니다.

XML style은 기존 Spring 사용자에게 가장 친숙할 수 있으며, genuine POJO에 의해 지원됩니다. AOP를 엔터프라이즈 서비스들을 구성하기 위한 도구로 사용할 때 XML은 좋은 선택이 될 수 있습니다(좋은 테스트는 포인트컷 표현식을 독립적으로 변경하고 싶어 할 수 있는 설정의 일부라고 보는지 여부입니다). XML style을 사용하면 설정에서 시스템에 어떤 aspects가 존재하는지가 더 명확하다고 볼 수 있습니다.

XML style에는 두 가지 단점이 있습니다. 첫째, 해결하려는 요구 사항의 구현을 단일 위치에 완전히 캡슐화하지 못합니다. DRY 원칙은 시스템 내의 어떤 지식 조각이든 단일하고 모호함이 없으며 authoritative한 표현이 있어야 한다고 말합니다. XML style을 사용할 때 요구 사항이 어떻게 구현되는지에 대한 지식은 backing 빈 클래스 선언과 설정 파일의 XML 사이에 나뉘어 있습니다.

@AspectJ style을 사용하면 이 정보는 단일 모듈인 aspect에 캡슐화됩니다. 둘째, XML style은 @AspectJ style에 비해 표현할 수 있는 것에 약간 제한이 있습니다. "singleton" aspect 인스턴스화 모델만 지원되며, XML에 선언된 named 포인트컷을 결합하는 것은 불가능합니다. 예를 들어, @AspectJ style에서는 다음과 같이 작성할 수 있습니다:

1@Pointcut("execution(* get*())")
2public void propertyAccess() {}
3
4@Pointcut("execution(com.xyz.Account+ *(..))")
5public void operationReturningAnAccount() {}
6
7@Pointcut("propertyAccess() && operationReturningAnAccount()")
8public void accountPropertyAccess() {}

1@Pointcut("execution(* get*())")
2fun propertyAccess() {}
3
4@Pointcut("execution(com.xyz.Account+ *(..))")
5fun operationReturningAnAccount() {}
6
7@Pointcut("propertyAccess() && operationReturningAnAccount()")
8fun accountPropertyAccess() {}

XML style에서는 처음 두 포인트컷을 다음과 같이 선언할 수 있습니다:

1<aop:pointcut id="propertyAccess"
2		expression="execution(* get*())"/>
3
4<aop:pointcut id="operationReturningAnAccount"
5		expression="execution(com.xyz.Account+ *(..))"/>

XML 접근 방식의 단점은 이러한 정의를 결합하여 accountPropertyAccess 포인트컷을 정의할 수 없다는 점입니다.

@AspectJ style은 추가적인 인스턴스화 모델과 더 풍부한 포인트컷 조합을 지원합니다. 또한 aspect를 모듈식 단위로 유지한다는 장점이 있습니다. 그리고 @AspectJ aspects는 Spring AOP와 AspectJ 모두에서 이해(그리고 소비)될 수 있다는 장점도 있습니다.

따라서 나중에 추가 요구 사항을 구현하기 위해 AspectJ의 기능이 필요하다고 판단되면, classic AspectJ 설정으로 쉽게 마이그레이션할 수 있습니다. 일반적으로 Spring 팀은 엔터프라이즈 서비스의 단순한 설정을 넘어서는 커스텀 aspects에 대해서는 @AspectJ style을 선호합니다.