Spring
Spring AOP: 횡단의 종결자!
noh.noah
2022. 10. 12. 21:01
AOP에 대하여
서비스 로직을 구현하다보면 그외 부가기능(인프라로직)을 어쩔 수 없이 구현해야하는 경우가 있다.
과연 꼭 필요한 로직일까? -> 사실상 메인기능이 서비스 로직이 필요함.
인프라 로직?
- 애플리케이션의 전 영역에서 나타날 수 있음
- 중복코드 만들어낼 가능성 때문에 유지보수 힘들어짐
- 비즈니스로직과 함꼐 있으면 비즈니스로직을 이해하기 어려워짐
우린 이 부분을 [Cores-curring cocern: 횡단 관심사] 개념으로 풀어나갈 수 있다!
AOP (Aspect-Oriented Programing) : 관점지향프로그래밍
OOP와 대치되지 않으며, 보다 객체지향적으로 구현할 수 있음 (Spring에서 권장하고 있다.)
AOP 용어
Target
- 어떤 대상에 부가기능을 부여할 것인가
Advice: 공통기능 각각의 로직
- 어떤 부가기능? Before, AfterReuturing,AfterThrowing,After,Around
Join Point: 공통 기능을 적용해야하는 메소드 (실행 시점)
- 어디에 적용할 것인가? 메서드, 필드, 객체, 생성자 등
Point cut: 공통 기능 적용할 대상
- 실제 advice가 적용될 지점, Spring AOP에서는 advice가 적용될 메서드를 지정
AOP의 구현방법
컴파일: AspectJ
- Runtime이 아닌 Compile 시점에 Aspect를 적용
클래스 로드: CGLIB (MethodInterceptor)
- CGLIB(Code Generator Library) - 코드 생성 라이브러리
- java proxy와 동일하게 런타임시에 Advice 적용
- 클래스에 대한 Proxy가 가능
- 메서드가 처음 호출 되었을때 동적으로 bytecode를 생성하여 이후 호출에서는 재사용
프록시 패턴
- 런타임시에 Target method가 호출될 때 Advice(프록시 할 기능)을 적용
- JDK Proxy는 인터페이스에 대한 Proxy만을 지원
- 리플렉션을 사용하여 구현한 기술이기에 상대적으로 퍼포먼스가 떨어짐
Spring AOP vs AspectJ
| Spring AOP | AspectJ |
| 순수 자바로 구현 | Java 프로그래밍 언어의 확장을 사용하여 구현 됨 |
| 별도의 컴파일 과정이 필요 없음 | LTW가 설정되지 않은 경우 AspectJ 컴파일러 (ajc)가 필요 |
| 런타임 위빙 만 사용할 수 있다 | 런타임 위빙을 사용할 수 없다. 컴파일 타임, 사후 컴파일 및로드 타임 Weaving 지원 |
| 덜 강력 함 – 메서드 수준 위빙 만 지원 | 더욱 강력 함 – 필드, 메서드, 생성자, 정적 이니셜 라이저, 최종 클래스 / 메서드 등을 엮을 수 있다. |
| Spring 컨테이너가 관리하는 Bean에서만 구현 가능 | 모든 도메인 개체에서 구현 가능 |
| 메서드 실행 포인트 컷 만 지원 | 모든 포인트 컷 지원 |
| 프록시는 대상 개체로 만들어지며 이러한 프록시에 측면이 적용 | 애플리케이션이 실행되기 전에 (런타임 전에) Aspect가 코드로 직접 짜여짐 |
| AspectJ보다 훨씬 느림 | 더 나은 성능 |
| 배우고 적용하기 쉬움 | Spring AOP보다 비교적 복잡함 |
간단히 말해, Spring AOP와 AspectJ는 다른 목표를 가지고 있다.
Spring AOP는 프로그래머가 직면하는 가장 일반적인 문제를 해결하기 위해 Spring IoC에서 간단한 AOP 구현을 제공하는 것을 목표로합니다. 완전한 AOP 솔루션 이 아니라 Spring 컨테이너가 관리하는 Bean에만 적용 할 수 있다.
반면 AspectJ는 완전한 AOP 솔루션을 제공하는 것을 목표로하는 독창적 인 AOP 기술이다. 더 강력하지만 Spring AOP보다 훨씬 더 복잡하다. AspectJ가 모든 도메인 객체에 적용될 수 있다는 점도 주목할 가치가 있다.
참고
- https://logical-code.tistory.com/118
- https://kils-log-of-develop.tistory.com/638