AOP 복습
AOP : 핵심 로직과 부가 기능을 분리하여 애플리케이션 전체에 걸쳐 사용되는 부가 기능을 모듈화하여 재사용할 수 있도록 지원하는 것 - 간단하게, 부가 기능(공통된 기능)의 모듈화를 통해 재사용
제대로 이해하고 있지 않다면 디버깅을 통해 어디서 문제가 생기는지 확인하기 어렵다는 단점이 있다.
적용 방식
- 컴파일 시점
- AspectJ가 제공하는 특별한 컴파일러가 필요하고, 복잡하다는 단점이 있다.
- 모든 지점에 적용 가능
- 클래스 로딩 시점
- 모든 지점에 적용 가능
- 특별한 옵션과 클래스 로더 조작기를 지정해야 하므로 운영하기 어려움
- 런타임 시점
- 스프링이 사용하는 방식
- 프록시는 메서드 오버라이딩 개념으로 작동하기 때문에 메서드에만 적용 가능, 스프링 빈에만 적용 가능
- 특별한 컴파일러나 조작기 등이 필요없기 때문에 스프링만 있으면 작동 가능
JDK 동적 프록시 ( = JDK Dynamic Proxy)
JDK 동적 프록시는 인터페이스 기반으로 프록시를 생성한다.
Service와 ServiceImpl이 있을 때,
Service 인터페이스 지정
- 빈으로 등록되어있는 프록시는 Service 인터페이스의 구현체다.
- 실제 동작할 때 Service는 빈으로 등록된 프록시의 부모이므로 AOP의 대상이 된다.
ServiceImpl 구체 클래스 지정
- this(hello.aop.member.MemberServiceImpl)
- 현재 빈으로 등록된 프록시는 MemberServiceImpl의 인터페이스인 MemberService 인터페이스의 구현체 입니다.
- 인터페이스의 구현체로 memberServiceImpl과 프록시가 있는 상태입니다.
- this는 프록시를 대상으로 하기 때문에 memberServiceImpl은 프록시의 부모가 아니므로 AOP의 대상이 아닙니다.
- target(hello.aop.member.MemberServiceImpl)
- 프록시의 대상 객체로 판단하기 때문에 MemberServiceImpl은 AOP 적용 대상입니다.
CGLIB 프록시
CGLIB은 구체 클래스 기반으로 프록시를 생성하여 빈으로 등록
MemberService 인터페이스를 지정했을 때
- this(hello.aop.member.MemberService), target(hello.aop.member.MemberService)
- 빈에 들어있는 프록시는 인터페이스의 구현체를 상속받아서 구현되었기 때문에 부모인 MemberService는 AOP의 대상이 됩니다.
MemberServiceImpl 구체 클래스 지정
- this(hello.aop.member.MemberServiceImpl)
- 빈에 들어있는 프록시는 인터페이스의 구현체를 상속받아서 구현되었기 때문에 부모인 MemberServiceImpl는 AOP의 대상이 됩니다.
- target(hello.aop.member.MemberServiceImpl)
- target 객체라 MemberServiceImpl로 일치하므로 AOP 적용 대상이 됩니다.
정리하자면, JDK 동적 프록시를 사용할 때, this의 대상을 구체 클래스로 지정하게 되면 구체 클래스의 인터페이스의 구현체가 프록시로 등록되면서 지정했던 구체 클래스는 AOP의 대상이 아닙니다.
CGLIB은 모두 AOP의 적용 대상이 됩니다.
즉, 프록시를 대상으로 하는 this의 경우 구체 클래스를 지정하면 프록시 생성 전략에 따라 다른 결과가 나올 수 있습니다.
사실 this와 target을 많이 사용하진 않기 때문에 구체 클래스(Impl)는 CGLIB의 경우 AOP의 대상이 되지만, JDK 동적 프록시의 대상이 되지 못한다 정도로 알아두면 됩니다.
이 이유때문에 Spring이 기본 프록시로 CGLIB을 선택하는데도 기여를 합니다.
WebMVC 와 JPA에 집중하자.
