aspect가 주어진 요구사항을 구현하기 위한 최선의 접근 방식이라고 결정했다면 Spring AOP 또는 AspectJ 사용과 Aspect 언어(코드) 스타일, @AspectJ 어노테이션 스타일 또는 Spring XML 스타일 중에서 어떻게 결정합니까? 이러한 결정은 애플리케이션 요구 사항, 개발 도구, AOP에 대한 팀의 친숙도 등 다양한 요소의 영향을 받습니다.

Spring AOP or Full AspectJ?

작동할 수 있는 가장 간단한 것을 사용하십시오. Spring AOP는 AspectJ 컴파일러/위버를 개발 및 빌드 프로세스에 도입할 필요가 없기 때문에 전체 AspectJ를 사용하는 것보다 간단합니다. Spring Bean에 대한 작업 실행을 advice해야 한다면 Spring AOP가 올바른 선택입니다. Spring 컨테이너에서 관리되지 않는 객체(예: 일반적으로 도메인 객체)를 advice해야 하는 경우 AspectJ를 사용해야 합니다. 간단한 메서드 실행(예: 필드 가져오기 또는 조인 포인트 설정 등) 이외의 조인 포인트를 advice하려는 경우에도 AspectJ를 사용해야 합니다.

AspectJ를 사용할 때 AspectJ 언어 syntax("코드 스타일"이라고도 함) 또는 @AspectJ annotation 스타일을 선택할 수 있습니다. aspect가 디자인에서 큰 역할을 하고 Eclipse용 AJDT(AspectJ 개발 도구) 플러그인을 사용할 수 있는 경우 AspectJ 언어 syntax가 선호되는 옵션입니다. 언어가 쓰기 aspect을 위해 의도적으로 설계되었기 때문에 더 깨끗하고 간단합니다. Eclipse를 사용하지 않거나 애플리케이션에서 중요한 역할을 하지 않는 몇 가지 aspect만 있는 경우 @AspectJ 스타일을 사용하고 IDE에서 일반 Java 컴파일을 고수하며 빌드 스크립트에 aspect 위빙 단계를 추가하는 것을 고려할 수 있습니다.

@AspectJ or XML for Spring AOP?

Spring AOP를 사용하기로 선택한 경우 @AspectJ 또는 XML 스타일을 선택할 수 있습니다. 고려해야 할 다양한 장단점이 있습니다.

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

XML 스타일에는 두 가지 단점이 있습니다. 첫째, 단일 위치에서 다루는 요구 사항의 구현을 완전히 캡슐화하지 않습니다. DRY 원칙은 시스템 내의 모든 지식에 대해 모호하지 않고 권위 있는 단일 표현이 있어야 한다고 말합니다. XML 스타일을 사용할 때 요구 사항이 구현되는 방법에 대한 지식은 구성 파일의 Backing Bean 클래스 선언과 XML에 걸쳐 분할됩니다. @AspectJ 스타일을 사용하면 이 정보는 단일 모듈인aspect에 캡슐화됩니다. 둘째, XML 스타일은 @AspectJ 스타일보다 표현할 수 있는 내용이 약간 더 제한됩니다. "싱글톤" aspect 인스턴스화 모델만 지원되며 XML에 선언된 명명된 포인트컷을 결합하는 것은 불가능합니다. 예를 들어 @AspectJ 스타일에서는 다음과 같이 작성할 수 있습니다.

@Pointcut("execution(* get*())")
public void propertyAccess() {}

@Pointcut("execution(com.xyz.Account+ *(..))")
public void operationReturningAnAccount() {}

@Pointcut("propertyAccess() && operationReturningAnAccount()")
public void accountPropertyAccess() {}

XML 스타일에서는 처음 두 포인트컷을 선언할 수 있습니다.

<aop:pointcut id="propertyAccess"
		expression="execution(* get*())"/>

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

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

@AspectJ 스타일은 추가 인스턴스화 모델과 더 풍부한 포인트컷 구성을 지원합니다. 모듈형 유닛으로서의 면모를 유지할 수 있는 장점이 있습니다. 또한 Spring AOP와 AspectJ 모두에서 @AspectJ aspect을 이해하고 사용할 수 있다는 장점도 있습니다. 따라서 나중에 추가 요구 사항을 구현하기 위해 AspectJ의 기능이 필요하다고 결정하면 클래식 AspectJ 설정으로 쉽게 마이그레이션할 수 있습니다. 일반적으로 Spring 팀은 엔터프라이즈 서비스의 단순한 구성 이상의 사용자 정의 aspect을 위해 @AspectJ 스타일을 선호합니다.