[빈 후처리기] 정리

 

문제1 - 너무 많은 설정

---

• 프록시를 직접 스프링 빈으로 등록하는 ProxyFactoryConfigV1 , ProxyFactoryConfigV2 와 같은 설정
  파일은 프록시 관련 설정이 지나치게 많다는 문제가 있다.
• 예를 들어서 애플리케이션에 스프링 빈이 100개가 있다면 여기에 프록시를 통해 부가 기능을 적용하려면
  100개의 프록시 설정 코드가 들어가야 한다. 
• 무수히 많은 설정 파일 때문에 설정 지옥을 경험하게 될 것이다.
• 스프링 빈을 편리하게 등록하려고 컴포넌트 스캔까지 사용하는데, 이렇게 직접 등록하는 것도 모자라서,
• 프록시를 적용하는 코드까지 빈 생성 코드에 넣어야 했다.

 

문제2 - 컴포넌트 스캔

---

• 애플리케이션 V3처럼 컴포넌트 스캔을 사용하는 경우 지금까지 학습한 방법으로는 프록시 적용이
  불가능했다.
• 왜냐하면 컴포넌트 스캔으로 이미 스프링 컨테이너에 실제 객체를 스프링 빈으로 등록을 다 해버린
  상태이기 때문이다.
• 좀 더 풀어서 설명하자면, 지금까지 학습한 방식으로 프록시를 적용하려면, 원본 객체를 스프링 컨테이너에
  빈으로 등록하는 것이 아니라 ProxyFactoryConfigV1 에서 한 것 처럼, 프록시를 원본 객체 대신 스프링
  컨테이너에 빈으로 등록해야 한다. 
• 그런데 컴포넌트 스캔은 원본 객체를 스프링 빈으로 자동으로 등록하기 때문에 프록시 적용이 불가능하다.

 

문제 해결

---

• 빈 후처리기 덕분에 프록시를 생성하는 부분을 하나로 집중할 수 있다. 
• 그리고 컴포넌트 스캔처럼 스프링이 직접 대상을 빈으로 등록하는 경우에도 중간에 빈 등록 과정을 가로채서 원본 대신에 프록시를 스프링 빈으로 등록할 수 있다.
• 덕분에 애플리케이션에 수 많은 스프링 빈이 추가되어도 프록시와 관련된 코드는 전혀 변경하지 않아도된다. 
• 그리고 컴포넌트 스캔을 사용해도 프록시가 모두 적용된다.

 

하지만 개발자의 욕심은 끝이 없다.

스프링은 프록시를 생성하기 위한 빈 후처리기를 이미 만들어서 제공한다.

 

 

중요

---

• 프록시의 적용 대상 여부를 여기서는 간단히 패키지를 기준으로 설정했다. 그런데 잘 생각해보면
  포인트컷을 사용하면 더 깔끔할 것 같다.
• 포인트컷은 이미 클래스, 메서드 단위의 필터 기능을 가지고 있기 때문에, 프록시 적용 대상 여부를 정밀하게
  설정할 수 있다.
• 참고로 어드바이저는 포인트컷을 가지고 있다. 따라서 어드바이저를 통해 포인트컷을 확인할 수 있다.
• 뒤에서 학습하겠지만 스프링 AOP는 포인트컷을 사용해서 프록시 적용 대상 여부를 체크한다.
• 결과적으로 포인트컷은 다음 두 곳에 사용된다.
  
  • 프록시 적용 대상 여부를 체크해서 꼭 필요한 곳에만 프록시를 적용한다. (빈 후처리기 - 자동 프록시생성)
  • 프록시의 어떤 메서드가 호출 되었을 때 어드바이스를 적용할 지 판단한다. (프록시 내부, 프록시 생성 후)