• IoC/DI, 서비스 추상화와 더불어 스프링의 3대 기반 기술의 하나인 AOP의 필연적인 등장 배경과 스프링이 그것을 도입한 이유, 적용을 통해 얻을 수 있는 장점이 무엇인지 충분한 이해가 필요하다.

🌱 Branch chapter06/refactor6.1에 실습 적용

비즈니스 로직을 담당하는 코드가 트랜잭션의 시작과 종료 작업 사이에서 수행되어야 한다는 사항을 지키되, 성격이 다른 코드를 두 개의 메소드로 분리

UserService implements : UserServiceImpl & UserServiceTx

Q. 타입으로 하나의 빈을 결정할 수 없는 경우(타입을 가진 빈이 2개 이상), 필드 이름을 이용해 빈을 찾는다

@Autowired
UserService userServiceTx;		// 필드 이름으로 검색

• 비즈니스 로직을 담당하고 있는 UserServiceImpl의 코드를 작성할 때는 트랜잭션과 같은 기술적인 내용에는 전혀 신경쓰지 않아도 된다
• 비즈니스 로직에 대한 테스트를 손쉽게 만들어낼 수 있다

🌱 Branch chapter06/refactor6.2에 실습 적용

작은 단위 테스트가 좋은 이유

• 테스트가 실패했을 때 그 원인을 찾기 쉽다
• 테스트의 의도나 내용이 분명해진다
• 테스트를 작성하기 쉽다

하지만, 테스트 대상이 다른 오브젝트와 환경에 의존하고 있다면 작은 단위의 테스트가 주는 장점을 얻기 힘들다

테스트의 대상이 환경이나, 외부 서버, 다른 클래스의 코드에 종속되고 영향을 받지 않도록 고립시킬 필요가 있다.

테스트를 의존 대상으로부터 분리해서 고립시키는 방법은 테스트를 위한 대역을 사용하는 것

그런데 의존 오브젝트나 외부 서비스에 의존하지 않는 고립된 테스트 방식을 만들었을 때, 기능이 수행이 되도 그 결과 기록이 남지않아 직접 결과를 검증하기 힘들다

-> 테스트 대상과 협력 오브젝트 사이에 주고 받은 정보를 저장해뒀다가, 테스트 검증에 사용할 수 있게하는 목 오브젝트를 만들어야한다.

• 비즈니스 로직을 검증하는 데 직접적으로 필요하지 않은 의존 오브젝트와 서비스를 모두 제거하고, 필요한 부분은 목 오브젝트를 생성해 최소화한다

  • 테스트 수행시간이 훨씬 큰 차이로 짧아졌다.
  • 테스트 수행 성능이 크게 향상되었다
  • 테스트가 다른 의존 대상에 영향을 받을 경우 대비해 복잡하게 준비할 필요가 없다

테스트 대상 클래스를 목 오브젝트 등의 테스트 대역을 이용해 의존 오브젝트나 외부의 리소스를 사용하지 않도록 고립시켜서 테스트하는 것

두 개 이상의, 성격이나 계층이 다른 오브젝트가 연동하도록 만들어 테스트하거나, 외부 DB나 파일, 서비스 등의 리소스가 참여하여 하는 테스트

• 단위 테스트를 우선시
• 외부와의 의존관계를 최소화하고 필요에 따라 스텁이나 목 오브젝트 등의 테스트 대역을 이용
• 외부 리소스를 사용해야만 가능한 테스트는 통합 테스트로 만듦
• 단위 테스트로 만들기 너무 복잡하다고 판단이 된다면, 처음부터 통합 테스트를 고려. 통합 테스트 참여 코드 중 최대한 많은 부분을 미리 단위 테스트로 검증해두기
• 스프링 테스트 컨텍스트 프레임워크를 이용하는 테스트는 통합 테스트다

• 단위 테스트를 만들기 위해서는 스텁이나 목 오브젝트의 사용이 필수적이다

• 대표적 프레임워크 : Mockito

  • Mockito로 만들어진 목 오브젝트는 메소드의 호출과 관련된 모든 내용을 자동으로 저장해두고, 이를 간단한 메소드로 검증할 수 있게 해준다

  1. 인터페이스를 이용해 목 오브젝트를 만든다
  2. 목 오브젝트가 리턴할 값이 있으면 이를 지정해준다. 메소드가 호출되면 예외를 강제로 던지게 만들 수 있다
  3. 테스트 대상 오브젝트에 DI 해서 목 오브젝트가 테스트 중에 사용되도록 만든다
  4. 테스트 대상 오브젝트를 사용한 후에 목 오브젝트의 특정 메소드가 호출됐는지, 어떤 값을 가지고 몇 번 호출됐는지 검증

  • any() : 파라미터 내용은 무시하고 호출 횟수만 확인 가능
  • times() : 메소드 호출 횟수를 검증해준다
  • ArgumentCaptor : 파라미터를 직접 비교하기보다는 파라미터의 내부 정보를 확인해야 하는 경우에 유용

• 목 프레임워크의 특징

  • 목 클래스를 일일이 준비해둘 필요가 없다
  • 간단한 메소드 호출만으로 다이내믹하게 특정 인터페이스를 구현한 테스트용 목 오브젝트를 만들 수 있다

🌱 Branch chapter06/refactor6.3에 실습 적용

• 자신이 클라이언트가 사용하려고 하는 실제 대상인 것 처럼 위장해서 클라이언트의 요청을 받아주는 것

• 대리자, 대리인과 같은 역할을 한다

• 타깃(target) or 실체(real subject) : 프록시를 통해 최종적으로 요청을 위임받아 처리하는 실제 오브젝트

• 프록시의 특징

  • 타깃과 같은 인터페이스를 구현
  • 프록시가 타깃을 제어할 수 있는 위치에 있다는 것

• 프록시의 구분 (사용 목적에 따른)

  1. 클라이언트가 타깃에 접근하는 방법을 제어하기 위한 목적
  2. 타깃에 부가적인 기능을 부여해주기 위한 목적
  • 두 가지 모드 대리 오브젝트라는 개념의 프록시를 두고 사용한다는 점은 동일하지만, 목적에 따라서 디자인 패턴에서는 다른 패턴으로 구분

• 타깃에 부가적인 기능을 런타임 시 다이나믹하게 부여해주기 위해 프록시를 사용하는 패턴
  • 런타임 시 다이나믹 -> 컴파일 시점, 코드 상에서는 프록시와 타깃을 연결하여 사용하지 않는다는 뜻
• 프록시가 딱 하나로 제한되어 있지 않고, 프록시가 직접 타깃을 사용하도록 고정시킬 필요도 없다
• 같은 인터페이스를 구현한 타겟과 여러 개의 프록시를 사용할 수 있다

1. 클라이언트와 사용 대상 사이에 대리 역할을 맡은 오브젝트를 두는 방법
2. 프록시를 사용하는 방법 중에서 타깃에 대한 접근 방법을 제어하려는 목적을 가진 경우 📌

• 다만 프록시는 코드에서 자신이 만들거나 접근할 타깃 클래스 정보를 구체적으로 알고 있는 경우가 많다
  • ex) 생성 지연 프록시의 경우, 타깃 클래스의 구체적인 생성 방법을 알아야함

앞으로의 프록시의 정의

1. 타깃과 동일한 인터페이스를 구현
2. 클라이언트와 타깃 사이에 존재
3. 부가 기능 또는 접근 제어 기능을 담당하는 오브젝트

• 프록시 : 기존 코드에 영향을 주지 않으면서 타깃의 기능을 확장하거나 접근 방법을 제어할 수 있는 유용한 방법

  • 자바의 java.lang.reflect 패키지 안에 프록시를 손쉽게 만들 수 있도록 지원해주는 클래스들이 있다

• 프록시를 만들기 번거로운 이유 두 가지

  1. 원하는 부가 기능을 위해 필요없는 메소드도 모두 구현해야한다
  2. 부가 기능 코드가 중복될 가능성이 많다

• 리플랙션

  • 다이나믹 프록시는 리플랙션 기능을 이용해서 프록시를 만들어 준다

    @Test
    public void invokeMethod() throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {
        String name = "Spring";
    
        // length()
        assertThat(name.length(), is(6));
    
        /**
        * Method ? 리플렉션 API 중에서 메소드에 대한 정의를 담은 인터페이스
        *          1. 메소드에 대한 자세한 정보를 담고 있음
        *          2. 특정 오브젝트의 메소드를 실행시킬 수 있다
        *          -> invoke() 메소드 사용
        */
        Method lengthMethod = String.class.getMethod("length");
        assertThat((Integer)lengthMethod.invoke(name),
    	//                               invoke(메소드를 실행시킬 타깃 오브젝트)
                   									is(6));
    
        // charAt()
        assertThat(name.charAt(0), is('S'));
    
        Method charAtMethod = String.class.getMethod("charAt", int.class);
        assertThat((Character)charAtMethod.invoke(name, 0),
        //                                 invoke(메소드를 실행시킬 타깃 오브젝트, 들어갈 파라미터)
     										              is('S'));
    }

• 다이나믹 프록시

  • 프록시 팩토리에 의해 런타임 시 다이나믹하게 만들어지는 오브젝트

  • 다이나믹 프록시 오브젝트는 타깃의 인터페이스와 같은 타입으로 만들어진다

  • 클라이언트는 다이나믹 프록시 오브젝트를 타깃 인터페이스를 통해 사용할 수 있다

    • 프록시 팩토리에게 인터페이스 정보만 제공해주면 해당 인터페이스를 구현한 클래스의 오브젝트를 자동으로 생성

  • 부가기능은 프록시 오브젝트와 독립적으로 InvocationHandler를 구현한 오브젝트에 담는다 : 모든 요청을 invoke() 메소드로 처리

  • 타깃 오브젝트 메소드 호출 + 부가 기능 = 결과 리턴 -> 클라이언트에게 전달

    Object newProxyInstance(
        ClassLoader loader,
        // 1. 다이나믹 프록시가 정의되는 클래스 로더를 제공
    	Class<?>[] interfaces,
        // 2. 프록시가 구현해야 할 인터페이스. 한 번에 하나 이상의 인터페이스를 구현할 수 있으므로 배열 사용 
    	InvocationHandler h
        // 3. 부가기능 & 위임 코드를 담고 있는 InvocationHandler 구현 오브젝트를 제공
    );

• 리턴 타입은 Method를 이용한 타깃 오브젝트의 메소드 호출 후 리턴타입을 확인해 특정 경우에만 반환
• 타깃의 종류에 상관없이 InvocationHandler 방식을 적용할 수 있다
• 단, 리플렉션 메소드인 Method.invoke()를 이용해 타깃 오브젝트의 메소드를 호출할 때는 타깃 오브젝트에서 발생하는 예외가 InvocationTargetException으로 한번 포장되어서 전달된다
  • getTargetException() 메소드로 중첩되어 있는 예외를 가져와야 한다

• DI의 대상이 되는 다이나믹 프록시 오브젝트는 일반적인 스프링의 빈으로 등록할 방법이 없다?

• 스프링 빈은 기본적으로 클래스 이름과 프로퍼티로 정의되며, 지정된 클래스 이름을 가지고 리플렉션을 이용해서 해당 클래스의 오브젝트를 만든다

  • Class의 newInstance() 메소드 : 해당 클래스의 디폴트 생성자를 호출해 오브젝트 생성 후 반환

    Date now = (Date) Class.forName("java.util.Date").newInstance();

• 다만! 다이나믹 프록시 오브젝트는 Proxy 클래스의 newProxyInstance() 스태틱 팩토리 메소드를 통해서만 만들 수 있다.

• 클래스 정보를 가지고 디폴트 생성자를 통해 오브젝트를 만드는 방법 이외에 빈 생성 방법

• 스프링을 대신해서 오브젝트의 생성로직을 담당

• 팩토리 빈을 만드는 대표적인 방법

  • FactoryBean 인터페이스를 구현한 클래스를 스프링의 빈으로 등록

스프링은 private 생성자를 가진 클래스도 빈으로 등록해주면 리플렉션을 이용해 오브젝트를 만들 수 있다

But, 생성자를 private으로 만들었다는 것은 스태틱 메소드를 통해 오브젝트를 만들어야 하는 이유가 있기 때문이므로 권장되지 않는다.

1. 스프링은 FactoryBean 인터페이스를 구현한 클래스가 빈의 클래스로 지정되면
2. 팩토리 빈 클래스의 오브젝트의 getObject() 메소드를 이용해 오브젝트를 가져오고
3. 이를 빈 오브젝트로 사용한다

• 장점

  • 프록시 팩토리 빈의 재사용. 코드의 수정 없이 다양한 클래스에 적용할 수 있다

• 한계점

  • 한 번에 여러 개의 클래스에 공통적인 부가 기능을 제공하는 것이 불가능하다
  • 하나의 타깃에 여러 개의 부가기능을 적용하려면 부가 기능의 개수만큼 프록시 팩토리 빈 설정이 붙어야한다
  • 타깃 오브젝트가 달라질 때마다 똑같은 부가기능을 제공하는 오브젝트를 중복적으로 만들어야한다

🌱 Branch chapter06/refactor6.4에 실습 적용

스프링은 일관된 방법으로 프록시를 만들 수 있게 도와주는 추상 레이어를 제공

생성된 프록시는 스프링의 빈으로 등록되어야 하고, 스프링은 프록시 오브젝트를 생성해주는 기술을 추상화한 팩토리 빈을 제공

프록시를 생성해서 빈 오브젝트로 등록하게 해주는 팩토리 빈

순수하게 프록시를 생성하는 작업만 담당, 프록시를 통해 제공해줄 부가 기능은 별도의 빈에 분리

TransactionHandler의 InvocationHandler가 아닌,

ProxyFactoryBean이 생성하는 프록시에서 사용하는 부가 기능은 MethodInterceptor 인터페이스를 구현하여 만든다

두 개의 차이점

• InvocationHandler : invoke() 메소드는 타깃 오브젝트에 대한 정보를 제공하지 않는다 -> 타깃 오브젝트에 대한 정보를 직접 알고 있어야 한다

• MethodInterceptor : invoke() 메소드는 ProxyFactoryBean으로부터 타깃 오브젝트 정보를 함께 제공받는다

  ▶ 그 덕분에 MethodInterceptor는 타깃 오브젝트에 상관없이 독립적으로 만들어질 수 있다

  ▶ MethodInterceptor 오브젝트는 타깃이 여러 프록시에서 함께 사용할 수 있고, 싱글톤 빈으로 등록 가능하다

Advice : 타깃 오브젝트에 적용하는 부가기능을 담은 오브젝튼

• MethodInvocation은 일종의 콜백 오브젝트로 proceed() 메소드를 실행하면 타깃 오브젝트의 메소드를 내부적으로 실행해주는 기능이 있다

• MethodInvocation 구현 클래스 : 일종의 공유 가능한 템플릿처럼 동작

  • JDK의 다이나믹 프록시를 직접 사용하는 코드와 가장 큰 차이점

• ProxyFactoryBean은 addAdvice()를 이용해 여러 개의 MethodInterceptor를 추가, 여러 부가 기능을 제공해주는 프록시를 만들 수 있다

• addAdvice로 MethodInterceptor 추가? ▶ MethodInterceptor는 Advice 인터페이스를 상속하고 있다

• ProxyFactoryBean은 구현해야 할 인터페이스를 알려주지 않아도 타깃 오브젝트가 구현하고 있는 인터페이스 정보를 알아내어 구현하는 프록시를 만든다

pointCut : 메소드 선정 알고리즘을 담은 오브젝트

• MethodInterceptor 오브젝트는 여러 프록시가 공유해서 사용할 수 있으며, 타깃 정보를 가지고 있지 않도록 구성되어 있다. -> 그렇기 때문에 스프링 싱글톤 빈으로 등록 가능하다
  • 트랜잭션 적용 대상 메소드 이름 패턴을 넣어주기 곤란. 패턴은 프록시마다 다를 수 있으며 여러 프록시가 공유하는 MethodInterceptor에 특정 프록시 적용 패턴을 넣을 수 없다
• MethodInterceptor는 프록시가 클라이언트로부터 받는 요청을 일일이 전달받을 필요 없이, 재사용 가능한 순수 부가기능 제공 코드만 남겨둔다

어드바이저 = 포인트컷(메소드 선정 알고리즘) + 어드바이스(부가기능)

🌱 Branch chapter06/refactor6.5에 실습 적용

☝ 아직 해결하지 못한 문제

• 부가기능의 적용이 필요한 타깃 오브젝트마다 거의 비슷한 내용의 ProxyFactoryBean 빈 설정정보를 추가해주는 부분이 중복됨

스프링은 컨테이너로서 제공하는 기능 중에서 변하지 않는 핵심적인 부분 외에는 대부분 확장할 수 있도록 확장 포인트를 제공해준다

▶️ BeanPostProcessor 인터페이스를 구현해서 만드는 빈 후처리기

* 빈 후처리기 : 이름 그대로 스프링 빈 오브젝트로 만들어지고 난 후에, 빈 오브젝트를 다시 가공할 수 있게 해줌

* 빈 후처리기를 스프링에 적용하는 방법

• 빈 후처리기 자체를 빈으로 등록

• 스프링은 빈 후처리기가 빈으로 등록되어 있으면 빈 오브젝트가 생성될 때마다 빈 후처리기에 보내서 후처리 작업 요청

• 빈 후처리기를 이용한 자동 프록시 생성 방법

  • 빈으로 등록된 모든 어드바이저 내의 포인트컷을 이용해 전달받은 빈이 프록시 적용 대상인지 확인
  • 프록시 적용 대상이라면, 내장된 프록시 생성기에게 현재 빈에 대한 프록시를 만들게 하고, 만들어진 프록시에 어드바이저를 연결
  • 빈 후처리기는 프록시가 생성되면 원래 컨테이너가 전달해준 빈 오브젝트 대신 프록시 오브젝트를 컨테이너에게 돌려줌
  • 컨테이너는 최종적으로 빈 후처리기가 돌려준 오브젝트(proxy)를 빈으로 등록하고 사용

• 이러한 부가기능 적용할 빈을 선정하는 로직이 추가된 포인트컷이 담긴 어드바이저를 등록하고 빈 후처리기 사용한다면, :golf: 일일이 ProxyFactoryBean 빈을 등록하지 않아도 타깃 오브젝트에 자동으로 프록시가 적용되게 할 수 있다! 🌟

포인트 컷은 클래스 필터와 메소드 매처 두가지를 돌려주는 메소드를 가지고 있다

• getClassFilter() : 프록시를 적용할 클래스인지 확인
• getMethodMatcher() : 어드바이스를 적용할 메소드인지 확인

Pointcut 선정 기능을 모두 적용한다면?

먼저 프록시를 적용할 클래스인지 판단 후, 적용 대상 클래스의 경우 어드바이스를 적용할 메소드인지 확인 후 동작

기존에 사용했던 포인트컷은 메소드 이름 패턴, 클래스 이름 패턴을 각각 클래스 필터와 메소드 매처 오브젝트로 비교해서 선정하는 방식

• 클래스 필터와 메소드 매처를 구현
• 스프링이 제공하는 필터나 매처 클래스를 가져와 프로퍼티 설정

• 일종의 표현식 언어를 사용해서 포인트컷을 작성할 수 있도록 하는 방법
• AspectJExpressionPointcut : 포인트컷 표현식을 지원하는 포인트컷
  • 클래스와 메소드의 선정 알고리즘을 포인트컷 표현식을 이용해 한 번에 지정할 수 있게 한다

• AspectJ 포인트컷 표현식은 포인트컷 지시자를 이용해 작성

• 포인트컷 지시자 대표적 : execution() -> 메소드를 실행에 대한 포인트컷

  • execution() 사용 표현식 문법구조

    execution( [접근제한자패턴] 리턴타입패턴 [패키지&클래스(인터페이스)이름패턴.]메소드이름패턴 (파라미터패턴 | .., ...))
    

• bean() : 스프링으로 사용될 때 빈의 이름으로 비교

  • ex) bean(*Service) : 아이디가 Service로 끝나는 모든 빈 선택

• @annotaion : 특정 어노테이션이 타입, 메소드, 파라미터에 적용되어 있는 상태를 보고 메소드 선정 포인트컷

  • ex) @annotaion(org.springframework.transaction.annotation.Transactional)

• 트랜잭션 서비스 추상화

  • 발생 문제점 : 특정 트랜잭션 기술에 종속되는 코드
  • 해결 : 트랜잭션 적용이라는 추상적인 작업 내용은 유지한 채로 구체적인 구현 방법을 자유롭게 바꿀수 있도록 서비스 추상화 기법 적용
  • 장점 : 인터페이스와 DI를 통해 무엇을 하는지는 남기고, 직접 구현은 분리함으로써 비즈니스 로직 코드에는 영향을 주지않고 독립적으로 변경 가능

• 프록시와 데코레이션 패턴

  • 발생 문제점 : 트랜잭션 적용 코드를 비즈니스 로직 코드에 노출시켜야했다
  • 해결 : DI를 이용해 데코레이션 패턴을 적용.클라이언트가 일종의 대리자인 프록시 역할을 하는 트랜잭션 데코레이터를 거쳐서 타깃에 접근 가능
  • 장점 : 비즈니스 로직 코드에 성격이 다른 코드로부터 독립시킬 수 있었고 독립적으로 로직을 검증하는 고립된 단위 테스트 생성 가능

• 다이나믹 프록시와 프록시 팩토리 빈

  • 발생 문제점 : 비즈니스 로직 인터페이스의 모든 메소드마다 트랜잭션 기능을 부여하는 코드를 넣어 프록시클래스를 만드는 작업이 번거로움
  • 해결 : JDK 다이나믹 프록시 기술 적용 -> 스프링 프록시 팩토리 빈을 이용해 다이나믹 프록시 생성 방법에 DI 도입
  • 장점 : 내부적으로 템플릿/콜백 패턴을 활용하는 스프링의 프록시 빈 덕분에 부가기능을 담은 어드바이스와 부가기능 선정 알고리즘을 담은 포인트것은 프록시에서 분리 가능. 여러 프록시가 공유해서 사용 가능

• 자동 프록시 생성 방법과 포인트컷

  • 발생 문제점 : 트랜잭션 적용 대상이 되는 빈마다 일일이 프록시 팩토리 빈을 설정해줘야 하는 번거로움
  • 해결 : 스프링 컨테이너의 빈 생성 후처리 기법을 활용해 컨테이너 초기화 시점에서 자동으로 프록시를 만들어주는 방법 도입. 클래스를 선정하는 기능을 담은 확장된 포인트컷 사용
  • 장점 : 부가 기능을 어디에 적용하는지에 대한 정보를 포인트컷이라는 독립적인 정보로 완전히 분리

• 그 자체로 애플리케이션의 핵심기능을 담고 있지는 않지만, 애플리케이션을 구성하는 중요한 한 가지 요소이고, 핵심 기능에 부가되어 의미를 갖는 특별한 모듈
• 부가될 기능을 정의한 코드인 어드바이스 + 어디에 적용할지를 결정하는 포인트컷

• 애플리케이션 핵심기능에서 부가기능을 분리해서 애스펙트라는 독특한 모듈로서 설계하고 개발하는 방법

• 애플리케이션을 특정한 관점을 기준으로 바라볼 수 있게 해준다는 의미

스프링은 다양한 기술을 조합해 AOP를 지원하고 있다. 그 중 가장 핵심은 프록시 이용 -> 프록시로 만들어서 DI로 연결된 빈 사이에 적용해 타깃의 메소드 호출 과정에 참여해서 부가 기능을 제공해주도록 만듦

스프링 AOP의 부가기능을 담은 어드바이스가 적용되는 대상은 오브젝트의 메소드. 프록시 방식을 사용했기 때문에 메소드 호출 과정에 참여해서 부가 기능을 제공해주게 되어 있다.

어드바이스가 구현하는 MethodInterceptor 인터페이스는 다이나믹 프록시의 InvocationHandler와 마찬가지로 프록시로부터 메소드 요청 정보를 전달받아서 타깃 오브젝트의 메소드를 호출.호출하는 전후에 다양한 부가기능 제공

프록시 : 독립적으로 개발한 부가기능 모듈을 다양한 타깃 오브젝트의 메소드에 다이나믹하게 적용하기 위해 가장 중요한 역할

스프링 AOP는 프록시 방식의 AOP라고 할 수 있다

• AspectJ는 프록시를 사용하지 않는 대표적인 AOP 기술

• 타깃 오브젝트를 뜯어고쳐서 부가기능을 직접 넣어주는 방법 사용

• 컴파일된 타깃의 클래스 파일 자체를 수정하거나 클래스가 JVM에 로딩되는 시점을 가로채서 바이트코드를 조작하는 방법 사용

• AspectJ가 컴파일된 클래스 파일 수정/바이트코드 조작같은 방법을 사용하는 이유

  • 바이트코드를 조작해서 타깃 오브젝트를 직접 수정해버리면 DI 컨테이너의 도움을 받아서 자동 프록시 생성방식을 사용하지 않고 AOP 적용 가능
  • 프록시 방식보다 훨씬 강력하고 유연한 AOP 가능
    • 프록시 AOP를 적용할 때 : 부가기능을 부여할 대상은 클라이언트가 직접 호출할 때 사용하는 메소드로 제한
    • 바이트코드를 직접 조작해서 AOP를 적용할 때 : 오브젝트의 생성, 필드 값의 조회와 조작, 스태틱 초기화 등 다양한 작업을 부가기능에 부여 가능

타깃

부가기능을 부여할 대상

핵심기능을 담은 클래스일 수 있지만 경우에 따라 다른 부가기능을 제공하는 프록시 오브젝트일 수 있다

어드바이스

타깃에게 제공할 부가기능을 담은 모듈

오브젝트로 정의하기도 하지만 메소드 레벨에서 정의할 수도 있다

조인포인트

어드바이스가 적용될 수 있는 위치

스프링의 프록시 AOP에서 조인 포인트는 메소드의 실행 단계 뿐

포인트컷

어드바이스를 적용할 조인 포인트를 선별하는 작업 또는 그 기능을 정의한 모듈

스프링의 조인 포인트는 메소드의 실행이므로 스프링의 포인트컷은 메소드를 선정하는 기능을 갖고 있다

프록시

클라이언트와 타깃 사이에 투명하게존재하면서 부가기능을 제공하는 오브젝트

DI를 통해 타깃 대신 클라이언트에게 주입되며, 클라이언트의 메소드 호출을 대신 받아서 타깃에 위임해주면서, 그 과정에 부가기능을 부여

어드바이저

포인트컷과 어드바이스를 하나씩 갖고 있는 오브젝트

스프링 AOP에만 특별하게 사용되는 용어

애스펙트

AOP의 기본 모듈

한 개 또는 그 이상의 포인트컷과 어드바이스의 조합으로 만들어지며 보통 싱글톤 형태의 오브젝트로 존재

스프링 AOP를 적용하기 위해 추가했던 빈(ex. 어드바이저, 포인트컷, 자동 프록시 etc..)들은 비즈니스 로직을 위한 빈과는 성격이 다르다.

이러한 빈들을 스프링 컨테이너에 의해 자동 인식되서 특별한 작업을 위해 사용됨

• 자동 프록시 생성기
  • 스프링의 DefaultAdvisorAutoProxyCreator 클래스를 빈으로 등록
  • 애플리케이션 컨텍스트가 빈 오브젝트를 생성하는 과정에 빈 후처리기로 참여
  • 빈으로 등록된 어드바이저를 이용해서 프록시를 자동으로 생성하는 기능 담당
• 어드바이스
  • 부가기능을 구현한 클래스를 빈으로 등록
• 포인트컷
  • 스프링의 AspectJExpressionPointcut을 빈으로 등록해서 사용
  • 어드바이스와 포인트컷을 프로퍼티로 참조하는 것 외에는 기능이 없다

🌱 Branch chapter06/refactor6.6에 실습 적용

💡 트랜잭션 매니저를 통해 트랜잭션을 시작할려고 할 때 getTransaction()이라는 메소드를 사용해 DefaultTransactionDefinition를 받아오는 이유는 무엇일까

트랜잭션의 경계에서 이미 진행중인 트랜잭션이 있을 때 또는 없을 때 어떻게 동작할 것인가를 결정하는 방식

• PROPAGATION_REQUIRED

  • 가장 많이 사용되는 트랜잭션 전파 속성
  • 진행 중인 트랜잭션이 없으면 새로 시작하고, 이미 시작된 트랜잭션이 있으면 이에 참여
  • A, B, A->B, B->A 네 가지의 조합 트랜잭션이 가능
  • DefaultTransactionDefinition의 트랜잭션 전파 속성

• PROPAGATION_REQUIRES_NEW

  • 항상 새로운 트랜잭션을 시작 (독립적인 트랜잭션을 보장할 때 사용)
  • 앞에서 시작된 트랜잭션이 있든 없든 상관없이 새로운 트랜잭션을 만들어서 독자적으로 동작하게 함

• PROPAGATION_NOT_SUPPORTED

  • 트랜잭션 없이 동작하도록 만들고, 진행 중인 트랜잭션이 있어도 무시

  • 트랜잭션을 무시하는 속성을 두는 이유?

    • 한꺼번에 적용되는 많은 메소드 중에 특정 메소드만 트랜잭션 적용에서 제외하려면, 포인트컷이 상당히 복잡해질 수 있다. 특정 메소드를 제외시킬 때 사용하는 속성

❗ 트랜잭션 매니저를 통해 트랜잭션을 시작할려고 할 때 getTransaction()이라는 메소드를 사용하는 이유는 트랜잭션 전파 속성이 있기 때문

• 모든 DB 트랜잭션은 격리수준을 가지고 있어야 한다

• 적절하게 격리수준을 조정해서 가능한 한 많은 트랜잭션을 동시에 진행시키면서도 문제가 발생하지 않게 하는 제어가 필요

• DefaultTransactionDefinition은 기본적으로 ISOLATION_DEFAULT 로 격리 수준이 설정되어있고, 특별한 작업을 수행하는 메소드의 경우에는 격리 수준을 지정할 필요가 있다

• 트랜잭션을 수행하는 제한시간 설정 가능
• DefaultTransactionDefinition의 기본 설정은 제한시간 없음
• 새로운 트랜잭션을 시작하는 PROPAGATION_REQUIRES_NEW, PROPAGATION_NOT_SUPPORTED와 함께 사용해야 의미 있음

• 트랜잭션 내에서 데이터를 조작하는 시도를 막아줄 수 있다
• 데이터 액세스 기술에 따라서 성능이 향상될 수 있다

메소드별로 다른 트랜잭션 정의를 적용하려면 어드바이스의 기능을 확장해야한다

스프링에는 편리하게 트랜잭션 경계설정 어드바이스로 사용할 수 있도록 만들어진 TransactionInterceptor가 존재

TransactionInterceptor의 동작 방식 = 기존의 TransactionAdvice + 트랜잭션 정의를 메소드 이름 패턴을 이용해 지정 가능

• PlatformTransactionManager
• Properties 타입 transactionAttributes : 트랜잭션 속성을 정의한 프로퍼티
  • TransactionDefinition 네 가지 기본 항목 + rollbackOn()
  • * rollbackOn() : 어떤 예외가 발생하면 롤백을 할 것인가 결정하는 메소드

• 런타임 예외 발생 시, 트랜잭션 롤백
• 체크 예외가 발생할 경우, 예외상황으로 해석하지 않고 일종의 비즈니스 로직에 따른 의미 있는 리턴 방식의 한 가지로 인식해 트랜잭션 커밋

• rollbackOn() 속성을 둬 기본원칙과 특정 예외에 따라 커스텀 가능

• 직접 타깃에 트랜잭션 속성 정보를 가진 어노테이션 지정
• @Transaction의 타깃 : 메소드 & 타입
• @Transaction을 트랜잭션 속성 정보로 사용할 때 ? : @Transaction가 부여된 모든 오브젝트를 자동으로 타깃 오브젝트로 인식 -> TransactionAttributeSourcePointcut 포인트컷 사용
• 메소드마다 다르게 설정할 수도 있다

@Transaction 트랜잭션 부가기능 적용 단위는 메소드이며, 유연한 속성 제어가 가능

But, 동일한 속성 정보를 가진 어노테이션을 반복적으로 메소드마다 부여하면 코드가 지저분해지고 실수 유발

▶️ @Transaction을 적용할 때 4단계 대체 정책

1. 타깃 메소드 : 구현 메소드
2. **타깃 클래스 **: 구현 클래스 내 모든 메소드
3. 선언 메소드 : 인터페이스 메소드
4. 선언 타입 : 인터페이스 타입 내 모든 메소드

4단계 순서대로 @Transaction이 적용됐는지 확인하고 가장 먼저 발견된 속성정보 사용

끝까지 발견되지 않으면 해당 메소드는 트랜잭션 적용대상 X

• AOP를 이용해 코드 외부에서 트랜잭션의 기능을 부여해주고 속성을 지정할 수 있게 하는 방법

• 개별 데이터 기술의 트랜잭션 API를 사용해 직접 코드 안에서 사용하는 방법

▶️ 스프링은 두 가지 경우 모두를 지원하고 있다

• 테스트 클래스/메소드에 @Transactional 어노테이션을 부여해주면 마치 타깃 클래스나 인터페이스에 적용된 것처럼 테스트 메소드에 트랜잭션 경계가 자동으로 설정
• 테스트에 적용된 @Transactional 은 테스트가 끝나면 자동 롤백된다
  • 강제 롤백이 아닌 메소드 테스트 내용이 DB에 반영하고 싶다면 @Rollback 이용
  • 메소드 레벨이 아닌 클래스 레벨에서 부여하는 롤백 속성 지정은 @TransactionConfiguration