AOP

AOP가 필요한 상황

메소드가 1000개 있을 때, 모든 메소드의 호출 시간을 측정하고 싶다면?

모든 메소드에 시간 측정 로직을 추가해야 한다.

999개 남았다..

문제

1. 시간을 측정하는 로직과 핵심 비즈니스의 로직이 섞여서 유지보수가 어렵다.
2. 시간을 측정하는 로직을 변경해야 한다면.. 모든 로직을 찾아가면서 변경해야 한다..
3. 그렇다고 시간을 측정하는 로직을 별도의 공통 로직으로 만들기가 매우 어렵다..

 

---

AOP의 적용

Aspect Oriented Programming (관점 지향 프로그래밍)

OOP를 보완하는 수단으로, 핵심적인 기능에서 부가적인 기능을 분리하는 기법(관심사의 분리)

분리한 부가 기능, 공통 로직을 Aspect라고 한다.

즉, 부가 기능을 중복 제거, 유지보수를 위해 하나로 모으는 기법

 

 

공통 관심 사항(cross-cutting concern)과 핵심 관심 사항(core concern)을 분리

시간을 측정하는 로직은 핵심 관심사항이 아니다. 공통 관심 사항이다.

분리하자!

 

 

시간 측정 AOP 등록

공통 관심 사항만을 모았다.

- Join point(합류점): 메소드 실행 시점, 끼어드는 시점

  ex) 생성자호출 직전, 필드 접근 전, 필드 값 get 할 때

 

 

스프링 설정 클래스에 등록

@Component 컴포넌트 스캔 이용해도 되지만 직접 등록하는 것을 선호한다고 한다

어떤 AOP가 적용되는지 한눈에 파악되기 때문

 

사용

※ 부가 효과: 흐름 파악
controller-service-repository-query-repository-service-controller
병목 지점을 찾을 수도 있다

 

해결 - 정리

- 회원 가입 등 핵심 관심 사항과 시간을 측정하는 공통 관심 사항을 분리하기 위해

   시간을 측정하는 로직을 별도의 Aspect로 만들었다.

- 이로써 핵심 관심 사항을 깔끔하게 유지할 수 있다.

- 부가 기능의 적용 대상을 설정할 수 있다. 변경이 필요하면 Aspect만 변경하면 된다.

 

 

---

스프링의 AOP 동작 방식

- AOP 적용 전 의존 관계

- AOP 적용 후 의존 관계

컨테이너는 가짜를 주입한다.

1. 스프링 컨테이너는 프록시(가짜 memberService)를 앞세운다.

▷ 컨트롤러가 프록시 memberService를 주입 받는다.

 

2. 컨트롤러 입장에서는 뭔지 모르고 받아서 쓰는데 알고보니 프록시

여기서 DI의 또 다른 장점: 컨테이너가 가짜를 만들어서 DI 해줄 수 있는 기반

3. Aspect가 실행되고 joinPoint.proceed()에 이르면 진짜가 호출된다

▷ 컨트롤러가 프록시 memberService를 호출하면 프록시 memberService가 실제 memberService를 호출

 

※ 실제로 memberService.getClass()로 출력해보면, 프록시(가짜 service 객체)가 호출됨을 확인할 수 있다.

실제 memberService와 레퍼런스 값이 다르다

 

- AOP 적용 전 전체 그림

- AOP 적용 후 전체 그림

메소드를 호출할 때마다 중간에서 인터셉트해서 execute()가 호출되고,

execute에서 joinPoint.proceed()로 작업을 이어 진행한다.

 

---

 

참고 자료 & 이미지 출처
스프링 입문(김영한 님)