스프링 AOP와 Aspect J

스프링 AOP와 Aspect J

Spring AOP는 커스텀 Java5 주석을 프레임워크로 사용하기 때문에 보안, 로깅, 트랜잭션 등의 애플리케이션 고유의 태스크에 가장 적합합니다.단, Aspect J는 보다 친숙한 디자인 패턴으로 보입니다.

Spring 어플리케이션에서 Spring AOP와 Aspect J를 사용하는 경우의 다양한 장단점을 강조해 주실 수 있습니까?

Spring-AOP 프로

• LTW(로드타임 위빙)나 AspectJ 컴파일러를 사용할 필요가 없기 때문에 AspectJ보다 사용하기 쉽습니다.

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

Spring-AOP 단점

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

AspectJ의 장점

• 이것은 모든 결합점을 지원합니다.이것은 당신이 무엇이든 할 수 있다는 것을 의미합니다.
• Spring AOP보다 런타임 오버헤드가 적습니다.

Aspect J의 단점

• 조심하세요.당신의 측면이 당신이 짜고 싶은 것에만 짜여져 있는지 체크하세요.
• AspectJ 컴파일러를 사용한 추가 빌드 프로세스가 필요하거나 LTW(로드 타임 위빙)를 설정해야 합니다.

기타 주의사항:부하가 높은 환경에서 퍼포먼스가 중요한 경우 Spring AOP보다 9-35배 빠른 Aspect J가 좋습니다.10ns 대 355ns는 그다지 많지 않은 것 같습니다만, 많은 Aspects를 사용하고 있는 사람을 봐 왔습니다.10K의 가치 있는 측면.이 경우 요청은 수천 가지 측면에 영향을 미칠 수 있습니다.이 경우 해당 요청에 ms를 추가합니다.

벤치마크를 참조해 주세요.

다른 사람들이 말한 것과는 별개로, 바꿔 말하면there are two major differences:

1. 하나는 직물의 종류와 관련이 있다.
2. 결합점 정의에 대한 다른 정의입니다.

Spring-AOP: 프록시를 통한 런타임 위빙:dynamic proxy if interface exists or cglib library if direct implementation provided.

Aspect J: 컴파일 시간 단축AspectJ Java Tools(ajc compiler)소스 또는 컴파일 후 위빙(컴파일된 파일 사용)이 가능한 경우.또한 스프링을 사용한 로드 타임 위빙이 활성화될 수 있습니다. - 스프링은 다음을 필요로 합니다.aspectj정의 파일 및 유연성을 제공합니다.

컴파일 타임 위빙은 퍼포먼스(경우에 따라서는)와joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.

스프링 유저 메뉴얼은 많은 정보를 직접 전해 줄 것이다.

6.4장 - 사용할 AOP 선언 스타일 선택에서는 이 두 가지 장단점을 모두 설명합니다.

6.1.2 - Spring AOP Capabilites and goals & 챕터 6.2 - @Aspect support 및 6.8 - Using Aspect J with Spring applications는 특히 흥미로울 것입니다.

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

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

봄의 AOP가 어떻게 기능하는지를 이해하기 위한 핵심 포인트는 봄과 함께 Aspect with Spring을 작성할 때 오브젝트의 프록시를 작성하는 프레임워크를 계측합니다.JDKDynamicProxy인터페이스가 구현되어 있는지, 인터페이스가 구현되어 있지 않은지 CGLIB를 통해 확인할 수 있습니다.버전 3.2보다 이전 Spring을 사용하는 경우 클래스 경로에 cglib 2.2가 있어야 합니다.봄 3.2부터는 cglib 2.2가 코어에 포함되었기 때문에 무용지물입니다.

Bean 작성 시 프레임워크는 오브젝트를 랩하는 프록시를 생성하여 보안, 트랜잭션 관리, 로깅 등의 크로스 컷 관련 업무를 추가합니다.

이 방식의 프록시 작성은 프록시로 작성되는 콩과 메서드를 결정하기 위해 프레임워크를 계측하는 포인트 컷 표현식부터 적용됩니다.당신의 코드보다 조언이 더 큰 책임이 될 것입니다.이 프로세스에서 포인트 컷은 최종으로 선언되지 않은 공개 메서드만 캡처합니다.

Spring AOP에서는 Aspects의 위빙이 컨테이너 시작 시 컨테이너에 의해 수행되지만, AspectJ에서는 바이트 코드 수정을 통해 코드를 편집한 후 이를 수행해야 합니다.이 때문에 스프링 어프로치가 Aspect J보다 간단하고 관리하기 쉽다고 생각합니다.

한편 Spring AOP에서는 구현이 프록시를 통해 이루어지므로 코드 수정이 아닌 AOP의 모든 기능을 사용할 수 없습니다.

AspectJ와 마찬가지로 SpringAOP에서는 로드타임 위빙을 사용할 수 있습니다.봄철에는 에이전트 및 특수 구성으로 구현되는 이 기능을 활용할 수 있습니다.@EnabledLoadWeaving또는 XML 형식입니다. name-space를 예로 사용할 수 있습니다.그러나 봄철 AOP에서는 모든 케이스를 가로채는 것은 아닙니다.예를 들어,newSpring AOP에서는 명령어가 지원되지 않습니다.

단, Spring AOP에서는 AspectJ를 사용하여aspectofspring configuration bean의 공장 출하 방법.

Spring AOP는 기본적으로 컨테이너에서 작성된 프록시이므로 AOP는 봄콩에만 사용할 수 있습니다.Aspect J를 사용하면 모든 콩에 Aspect를 사용할 수 있습니다.또 하나의 비교 포인트는 디버깅과 코드 동작의 예측 가능성입니다.Spring AOP를 사용하면 작업은 모두 Java 컴파일러에서 미리 생성되며 Spring bean용 프록시를 만드는 매우 멋진 방법입니다.Aspect J에서는 코드를 수정하는 경우 컴파일이 더 필요하며, 자신의 측면이 어디에 짜여져 있는지 이해하기 어려울 수 있습니다.봄에는 직조 작업을 정지하는 것조차 간단합니다.봄에는 구성 요소를 제거하고 재기동하면 동작합니다.AspectJ에서는 코드를 다시 컴파일해야 합니다!

부하 시간 직조에서는 스프링이 AspectJ의 모든 옵션을 지원하지 않기 때문에 스프링보다 AspectJ가 더 유연합니다.단, 콩의 작성 프로세스를 변경하고 싶다면 새로운 오퍼레이터의 동작을 바꾸는 측면의 로드 타임 위빙이 아닌 공장에서 커스텀 로그인을 관리하는 것이 더 좋은 방법이라고 생각합니다.

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

이 기사에는 주제에 대한 설명도 잘 되어 있습니다.

Spring AOP와 Aspect J의 목표는 다릅니다.

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

한편, Aspect J는 완전한 AOP 솔루션을 제공하는 것을 목표로 하는 독창적인 AOP 테크놀로지입니다.

고객의 측면이 미션 크리티컬한지 여부와 코드가 어디에 배치되어 있는지를 고려하는 것이 중요합니다.스프링 AOP는 부하 시간 직조에 의존하고 있음을 의미합니다.이는 위빙에 실패할 수 있으며, 제 경험상 기록된 오류는 존재할 수 있지만 애스펙트 코드 없이 응용 프로그램을 실행할 수 없도록 하는 것은 아닙니다(이러한 경우와는 다른 방법으로 구성할 수 있다는 주의사항을 추가합니다.그러나 개인적으로 알고 있지는 않습니다).컴파일 타임의 짜임새에 의해서, 이것을 회피할 수 있습니다.

Additionally, If you use AspectJ in conjunction with the aspectj-maven-plugin then you are able to run unit tests against your aspects in a CI environment and have confidence that built artifacts are tested and correctly woven. While you can certainly write Spring driven unit tests, you still have no guarantee that the deployed code will be that which was tested if LTW fails.

Another consideration is whether you are hosting the application in an environment where you are able to directly monitor the success or failure of a server / application startup or whether your application is being deployed in an environment where it is not under your supervision [e.g. where it is hosted by a client]. Again, this would point the way to compile time weaving.

Five years ago, I was much more in favour of Spring configured AOP for the simple reason that it was easier to work with and less likely to chew up my IDE. However, as computing power and available memory have increased this has become much less of an issue and CTW with the aspectj-maven-plugin has become a better choice in my work environment based on the reasons I have outlined above.

Compared to AOP, AspectJ does not need to enhance the target class at compile time. Instead, it generates a proxy class for the target class at runtime, which either implements the same interface as the target class or is a subclass of the target class.

In summary, an instance of a proxy class can be used as an instance of a target class. In general, the compile-time enhanced AOP framework is more advantageous in performance—because the runtime-enhanced AOP framework requires dynamic enhancements every time it runs.

ReferenceURL : https://stackoverflow.com/questions/1606559/spring-aop-vs-aspectj