스프링 AOP 대 AspectJ

스프링 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.

---

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

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

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

---

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

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

---

스프링 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에서는 코드를 다시 컴파일해야합니다!

In load-time weaving, AspectJ is more flexible than Spring because Spring doesn't support all of the options of AspectJ. But in my opinion If you want to change the creation process of a bean, a better way is to manage the custom login in a factory and not with load-time weaving of an aspect that changes the behavior of your new operator.

I hope that this panoramic of AspectJ and Spring AOP helps you understand the difference of the two potions

---

It is important to consider whether your aspects will be mission critical and where your code is being deployed. Spring AOP will mean that you are relying on load-time weaving. This can fail to weave and in my experience has meant that logged errors may exist but will not prevent the application from running without aspect code [I would add the caveat that it may be possible to configure it in such a way that this is not the case; but I am not personally aware of it]. Compile-time weaving avoids this.

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.

---

This article also has a good explanation regarding the topic.

Spring AOP and AspectJ have different goals.

Spring AOP aims to provide a simple AOP implementation across Spring IoC to solve the most common problems that programmers face.

On the other hand, AspectJ is the original AOP technology which aims to provide complete AOP solution.

참고URL : https://stackoverflow.com/questions/1606559/spring-aop-vs-aspectj