스코프와 프록시

꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다.

 

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger { ~ }

@Scope( value = "request", proxyMode = ScopedProxyMode.  ~  ) 에서
적용 대상이 클래스면 TARGET_CLASS , 인터페이스면 INTERFACES

 

이렇게 하면 MyLogger의 가짜 프록시 객체를 생성해서, HTTP request와 상관 없이 가짜 프록시 객체를 다른 빈에 미리 주입해 둘 수 있다.

 

주입된 MyLogger를 확인해보면

MyLogger$$SpringCGLIB$$0 이러한 형태다

 

스프링 컨테이너는

CGLIB( 바이트코드를 조작하는 라이브러리 )를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성해서 주입한다

( 스프링 컨테이너에 "myLogger"라는 이름으로 진짜 대신에 이 가짜 프록시 객체를 등록한다 )

 

가짜 프록시 객체는 실제 요청이 오면( ex 메소드를 실제 호출 ) 그때 내부에서 실제 빈을 요청( 이때, 실제 빈이 생성됨 )하는 위임 로직이 들어있다.

가짜 프록시 객체는 내부에 단순한 위임 로직만 있고, 싱글톤 처럼 동작한다

클라이언트가 myLogger.log() 을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것이다.
가짜 프록시 객체는 request 스코프의 진짜 myLogger.log() 를 호출한다

 

프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다

Provider , 프록시 모두 
핵심 아이디어는 진짜 객체 조회( 빈 생성 )를  내가 원하는 시점( 생성가능한 시점 )에 할수 있다는 것 

( provider는 get메소드로 직접 빈을 얻어서 사용 , 프록시는 프록시빈이 마치 진짜인양 act )

 

단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. 

이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다