스프링 AOP 대 AspectJ

Spring AOP는 사용자 정의 Java5 주석을 프레임 워크로 사용하므로 보안, 로깅, 트랜잭션 등과 같은 응용 프로그램 특정 작업에 가장 적합하다는 인상을 받았습니다. 그러나 AspectJ는 더 친숙한 디자인 패턴 인 것 같습니다.

Spring 애플리케이션에서 Spring AOP vs AspectJ를 사용하는 다양한 장단점을 강조 할 수 있습니까?

스프링 AOP 프로

• LTW ( load-time weaving ) 또는 AspectJ 컴파일러 를 사용할 필요가 없으므로 AspectJ보다 사용이 더 간단합니다 .

• 프록시 패턴과 데코레이터 패턴을 사용합니다.

스프링 AOP 단점

• 프록시 기반 AOP이므로 기본적으로 메소드 실행 조인 포인트 만 사용할 수 있습니다.
• 동일한 클래스 내에서 다른 메소드를 호출 할 때는 화면비가 적용되지 않습니다.
• 약간의 런타임 오버 헤드가있을 수 있습니다.
• Spring-AOP는 Spring 팩토리에서 작성하지 않은 항목에 화면비를 추가 할 수 없습니다

AspectJ 전문가

• 모든 조인 포인트를 지원합니다. 이것은 당신이 무엇이든 할 수 있음을 의미합니다.
• Spring AOP보다 런타임 오버 헤드가 적습니다.

AspectJ 단점

• 조심해. 당신이 직조하고 싶었던 것으로 만 직조되어 있는지 확인하십시오.
• AspectJ Compiler를 사용하여 추가 빌드 프로세스가 필요하거나 LTW (로드 시간 직조)를 설정해야합니다.

다른 사람들이 말한 것 외에도-다시 말하면 there are two major differences:

1. 하나는 직조의 유형과 관련이 있습니다.
2. 조인 포인트 정의에 대한 또 다른 것.

Spring-AOP : 개념을 사용하여 프록시를 통한 런타임 위빙dynamic proxy if interface exists or cglib library if direct implementation provided.

AspectJ :AspectJ Java Tools(ajc compiler) 소스가 사용 가능한 경우 또는 컴파일 후 제직 (컴파일 된 파일 사용)을 통해 컴파일 시간 짜기 . 또한 스프링으로 직조하는로드 시간을 활성화 할 수 있습니다. aspectj정의 파일 이 필요하고 유연성을 제공합니다.

컴파일 타임 제직은 성능 (일부 경우) 및 joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.

추가 참고 사항 : 높은 부하에서 성능이 중요한 경우 Spring AOP보다 9-35x 빠른 AspectJ가 필요 합니다. 10ns 대 355ns는별로 들리지 않지만 LOTS of Aspects를 사용하는 사람들을 보았습니다. 10K는 가치가 있습니다. 이 경우 귀하의 요청은 수천 가지 측면에 해당 될 수 있습니다. 이 경우 해당 요청에 ms를 추가합니다.

벤치 마크를 참조하십시오 .

스프링 사용자 매뉴얼 은 말의 입에서 곧바로 많은 정보를 제공합니다.

6.4 장 -사용할 AOP 선언 스타일 선택 은 두 가지의 장단점을 논의하기 때문에 당신을 위해 죽었습니다.

단락 6.1.2 - 스프링 AOP Capabilites과 목표 및 장 6.2 - @Aspect 지원 및 6.8 - 봄 응용 프로그램과 AspectJ의 사용은 particularily 히 흥미 있어야한다.

스프링 AOP는 스프링 프레임 워크의 필수 부분 중 하나입니다. 매우 기본적인 단계에서 스프링 프레임 워크는 IoC 및 AOP를 기반으로합니다. Spring의 공식 과정에는 다음과 같은 슬라이드가 있습니다.

AOP는 프레임 워크에서 가장 중요한 부분 중 하나입니다.

Spring에서 AOP가 작동하는 방식을 이해하는 핵심 포인트는 Spring을 사용하여 Aspect를 작성할 때 JDKDynamicProxybean이 인터페이스를 구현하는 경우 또는 bean이 구현하지 않으면 CGLIB를 통해 객체에 대한 프록시를 작성하여 프레임 워크를 계측한다는 것입니다. 상호 작용. 3.2 이전 버전의 Spring을 사용하는 경우 클래스 경로에 cglib 2.2가 있어야합니다. Spring 3.2부터는 cglib 2.2가 코어에 포함되어 있기 때문에 쓸모가 없습니다.

Bean 작성시 프레임 워크는 오브젝트를 랩핑하고 보안, 트랜잭션 관리, 로깅 등과 같은 교차 절단 문제를 추가하는 프록시를 작성합니다.

이러한 방식으로 프록시 작성은 프레임 워크를 계측하여 프록시로 작성 될 Bean 및 메소드를 결정하는 포인트 컷 표현식부터 적용됩니다. 조언은 코드보다 책임이 더 큽니다. 이 프로세스에서 pointcut은 final로 선언되지 않은 공개 메소드 만 캡처합니다.

이제 Spring AOP에서 컨테이너 시작시 컨테이너가 Aspects의 직조를 수행하지만 AspectJ에서는 바이트 코드 수정을 통해 코드의 포스트 컴파일 로이 작업을 수행해야합니다. 이런 이유로 Spring의 접근 방식은 AspectJ보다 간단하고 관리하기 쉽다.

반면 Spring AOP를 사용하면 구현이 코드 수정이 아닌 프록시를 통해 수행되므로 AOP의 모든 기능을 사용할 수 없습니다.

AspectJ와 마찬가지로 SpringAOP에서로드 타임 직조를 사용할 수 있습니다. 스프링이 에이전트 및 특수 구성 @EnabledLoadWeaving또는 XML 로 구현 된 경우이 기능을 활용할 수 있습니다 . 네임 스페이스를 예로 사용할 수 있습니다. 그러나 Spring AOP에서는 모든 경우를 가로 챌 수 없습니다. 예를 들어, new명령은 Spring AOP에서 지원되지 않습니다.

그러나 Spring AOP aspectof에서는 스프링 구성 Bean에서 팩토리 메소드를 사용하여 AspectJ를 사용하면 이점을 얻을 수 있습니다 .

Spring AOP가 기본적으로 컨테이너에서 작성된 프록시이므로 AOP를 스프링 Bean에만 사용할 수 있습니다. AspectJ를 사용하면 모든 Bean에서 Aspect를 사용할 수 있습니다. 다른 비교 포인트는 디버그와 코드 동작의 예측 가능성입니다. Spring AOP를 사용하면 Java 컴파일러에서 작업이 모두 수행되며 Spring bean에 대한 프록시를 생성하는 매우 멋진 방법입니다. AspectJ에서 코드를 수정하면 더 많은 컴파일이 필요하고 어스 팩트가 짜여진 위치를 이해하는 것이 어려울 수 있습니다. 스프링에서 직조를 종료하는 것조차 더 간단합니다. 스프링으로 구성에서 측면을 제거하고 다시 시작하면 작동합니다. AspectJ에서는 코드를 다시 컴파일해야합니다!

로드 타임 직조에서 Spring은 AspectJ의 모든 옵션을 지원하지 않기 때문에 AspectJ는 Spring보다 유연합니다. 그러나 내 의견으로는 Bean의 작성 프로세스를 변경하려면 새 운영자의 동작을 변경하는 측면의로드 시간 직조가 아닌 팩토리에서 사용자 정의 로그인을 관리하는 것이 좋습니다.

AspectJ와 Spring AOP의이 파노라마가 두 물약의 차이점을 이해하는 데 도움이되기를 바랍니다.

업무 측면이 중요하고 코드가 배포되는 위치를 고려해야합니다. Spring AOP는 하중 시간 직조에 의존하고 있음을 의미합니다. 이것은 직조에 실패 할 수 있으며 내 경험에 따르면 기록 된 오류가있을 수 있지만 종횡비 코드없이 응용 프로그램을 실행하지 못하게합니다 하지는 않습니다. 케이스; 그러나 나는 그것을 개인적으로 알지 못한다 . 컴파일 타임 제직은 이것을 피합니다.

또한 AspectJ를 aspectj-maven-plugin과 함께 사용하면 CI 환경에서 사용자의 측면에 대해 단위 테스트를 실행할 수 있으며 빌드 된 아티팩트가 올바르게 테스트되고 짜여 질 수 있습니다. Spring 구동 단위 테스트를 확실히 작성할 수는 있지만 배치 된 코드가 LTW가 실패한 경우 테스트 된 코드 일 것이라는 보장은 없습니다.

또 다른 고려 사항은 서버 / 응용 프로그램 시작의 성공 또는 실패를 직접 모니터링 할 수있는 환경에서 응용 프로그램을 호스팅하는지 또는 응용 프로그램이 감독 대상이 아닌 환경 (예 : 응용 프로그램 위치)에 배포되는지 여부입니다. 클라이언트가 호스팅합니다]. 다시 말하지만, 이것은 시간 짜기 컴파일 방법을 가리킬 것입니다.

5 년 전, 나는 IDE로 작업하기가 쉽고 IDE를 씹을 가능성이 적기 때문에 Spring 구성 AOP에 훨씬 유리했다. 그러나 컴퓨팅 성능과 사용 가능한 메모리가 증가함에 따라 이것은 훨씬 덜 문제가되었으며 Aspectj-maven-plugin을 사용한 CTW는 위에서 설명한 이유에 따라 작업 환경에서 더 나은 선택이되었습니다.

이 기사 에는 주제에 대한 좋은 설명도 있습니다.

Spring AOP와 AspectJ는 다른 목표를 가지고 있습니다.

Spring AOP는 Spring IoC에서 간단한 AOP 구현을 제공하여 프로그래머가 직면하는 가장 일반적인 문제를 해결하는 것을 목표로합니다.

반면 AspectJ는 완벽한 AOP 솔루션을 제공하는 것을 목표로하는 독창적 인 AOP 기술입니다.

AOP에 비해 AspectJ는 컴파일 타임에 대상 클래스를 향상시킬 필요가 없습니다. 대신 런타임에 대상 클래스에 대한 프록시 클래스를 생성합니다.이 클래스는 대상 클래스와 동일한 인터페이스를 구현하거나 대상 클래스의 서브 클래스입니다.

요약하면 프록시 클래스의 인스턴스를 대상 클래스의 인스턴스로 사용할 수 있습니다. 일반적으로 컴파일 시간이 향상된 AOP 프레임 워크는 성능이 더 유리합니다. 런타임 강화 AOP 프레임 워크는 실행될 때마다 동적 향상이 필요하기 때문입니다.