[스프링 스터디 2일차] AOP
- 1. AOP
- 2. Agenda 서비스 추상화 프록시와 데코레이터 패턴 다이내믹 프록시와 프록시 팩토리 빈 자동 프록시 생성 방법과 포인트 컷 AOP (Aspect Oriented Programming) AOP 네임스페이스 Ref.) AOP 용어 정리
- 3. 서비스 추상화 이슈 특정 트랜잭션 기술에 종속되는 코드 로컬 트랜잭션 방식을 분산 트랜잭션 방식으로 바꾸려면 모든 트랜잭션 코드를 수정해야 한다.
- 4. 서비스 추상화 1차 해결 비즈니스 로직을 담당하는 코드를 메서드로 추출 하여 독립시키는것 비즈니스 로직 코드만 독립적인 메서드로 분리되 어 있으니 이해하기도 편하고 수정 시 실수로 트랜잭션 코드를 건드릴 염려도 없어짐 여전히 한 클래스안에 트랜잭션 코드가 존 재
- 5. 서비스 추상화 DI를 적용한 트랜잭션 분리 UserService에는 순수하게 비즈니스 로 직을 담고 있는 코드만 놔두고 트랜잭 션 경계설정을 담당하는 코드를 외부 로 빼내려는 것
- 6. 서비스 추상화 UserService 인터페이스를 만든 후 UserServiceImpl이 구현 UserServiceImpl에서 비즈니스 로직을 제외한 트랜잭션 관련 코드들은 모두 제거 기술이나 서버환경, 스프링관련 코드도 보이지 않음. 비즈니스 로직에 충실한 깔끔한 코드
- 7. 서비스 추상화 UserService 인터페이스를 통해 사용자 관리 로직을 이용하려고 할 때 트랜잭션 작업 진 행 후 비즈니스 로직 수행 UserServiceTx의 빈 아이디가 UserService UserService 빈은 UserServiceImpl 빈을 DI
- 8. 서비스 추상화 이렇게 수정을 하면서 얻은 것은 무엇인가 비즈니스 로직을 담당하고 있는 코드를 작성할 때 트랜잭션과 같은 기술적인 내 용에 신경 쓰지 않아도 된다. 기술적인 지식이 부족하더라도 비즈니스 로직을 잘 이해하고 있다면 비즈니스 로 직은 담은 서비스 클래스를 개발할 수 있다.
- 9. 프록시와 데코레이터 패턴 위 그림과 같이 부가기능 전부를 핵심 코드가 담긴 클래스에서 독립시켜 지금까 지 코드를 진행 부가기능이 핵심기능을 사용하는 구조 클라이언트가 핵심 기능을 가진 클래스를 직접 사용 시 부가 기능이 적용될 기회 가 없다
- 10. 프록시와 데코레이터 패턴 부가 기능을 핵심 기능을 가진 클래스인 것처럼 꾸며 클라이언트가 부가 기능을 거쳐서 핵심 기능을 사용하도록 구성 클라이언트는 인터페이스를 통해서 핵심기능을 사용 부가기능도 같은 인터페이스를 구현한뒤 자신이 그사이에 끼어든다. 부가기능 코드에서 핵심기능으로 요청을 위임해주는 과정에서 자신이 가진 부가 적인 기능을 적용 가능.( ex. 트랜잭션 기능을 부여)
- 11. 프록시와 데코레이터 패턴 클라이언트가 사용하려고 하는 실제 대상인 것처럼 위장해서 클라이언트의 요청 을 받아주는 것을 대리자, 대리인 같은 역할을 한다고 해서 ‘프록시’ 라고 한다. 프록시를 통해 최종적으로 요청을 위임받아 처리하는 실제 오브젝트를 타깃 (target) 또는 실체(real subject) 클라이언트가 프록시를 통해 타깃을 사용하는 구조
- 12. 프록시와 데코레이터 패턴 프록시의 특징 타깃과 같은 인터페이스를 구현 프록시가 타깃을 제어할 수 있는 위치에 있다 프록시의 사용 목적 클라이언트가 타깃에 접근하는 방법을 제어하기 위해 타깃에 부가적인 기능을 부여해주기 위해 프록시를 두고 사용한다는 점은 동일하지만, 목적에 따라서 디자인 패턴에서는 다른 패턴으로 구 분 데코레이터 패턴 vs 프록시 패턴
- 13. 프록시와 데코레이터 패턴 데코레이터 패턴 타깃에 부가적인 기능을 런타임 시 다이내믹하게 부여해주기 위해 프록시를 사용하는 패턴 코드상에서는 어떤 방법과 순서로 프록시와 타깃이 연결되어 사용 되는지 정해져 있지 않다는 것
- 14. 프록시와 데코레이터 패턴 프록시 패턴 클라이언트가 타깃에 접근하는 방식을 변경 타깃의 기능 자체에는 관여하지 않으면서 접그하는 방법을 제어해주는 프록시를 이용하는 것 구조적으로 프록시와 데코레이터는 유사 인터페이스를 통해 다음 호출 대상으로 접근하게 하면 그 사이에 다른 프록시나 데코레이터가 계 속 추가 될 수 있다.
- 15. 다이내믹 프록시와 프록시 팩토리 빈 프록시 작성의 문제점 타깃의 인터페이스를 구현하고 위임하는 코드를 작성 하기 번거롭고 타깃 인터페이스의 메서드가 추가되 거나 변경될 때마다 함께 수정해야 한다는 부담 부가기능 코드가 중복될 가능성이 많다 메서드가 많아지면 유사코드가 여러 메서드에 중복돼서 나타날 것 위와 같은 문제를 해결하기 위해 유용한 것이 JDK 다이내믹 프록시!
- 16. 다이내믹 프록시와 프록시 팩토리 빈 다이내믹 프록시는 리플렉션 기능을 이용해서 프록시를 만든다. 리플렉션 - 자바의 코드 자체를 추상화해서 접근하도록 만든 것
- 17. 다이내믹 프록시와 프록시 팩토리 빈
- 18. 다이내믹 프록시와 프록시 팩토리 빈
- 19. 다이내믹 프록시와 프록시 팩토리 빈
- 20. 다이내믹 프록시와 프록시 팩토리 빈 InvocationHandler를 구현 Proxy 클래스의 newProxyInstance() 스태틱 팩토리 메서드를 이용해서 다이내믹 프록시를 생성
- 21. 다이내믹 프록시와 프록시 팩토리 빈
- 22. 다이내믹 프록시와 프록시 팩토리 빈
- 23. 다이내믹 프록시와 프록시 팩토리 빈 프록시 팩토리 빈 방식의 장점 다이내믹 프록시를 이용하면서 타깃 인터페이스를 구현하는 클래스를 일일이 만드는 번거로움 제 거 하나의 헨들러 메서드를 구현하여 수많은 메서드에 부가기능을 부여함으로써 부가기능 코드의 중 복 문제 해결 프록시에 팩토리 빈을 이용한 DI까지 더해주면 번거로운 다이내믹 프록시 생성 코드 제거 및 다양 한 타깃 오브젝트에 적용 가능
- 24. 다이내믹 프록시와 프록시 팩토리 빈 프록시 팩토리 빈의 한계 하나의 클래스 안에 존재하는 여러 개의 메서드에 부가기능을 한 번에 제공하는 것은 가능하지만 한 번에 여러개의 클래스에 공통적인 부가기능을 제공하는 일은 불가능 하나의 타깃에 여러 개의 부가기능을 적용하려고 할때도 문제 타깃 오브젝트에 트랜잭션 프록시뿐 아니라 보안기능, 로깅 등과 관련한 프록시를 추가 하려 면? 적용 대상인 서비스 클래스가 200개쯤 된다면? 코드 수정없이 설정의 변경만으로 수천 개 이상의 메서드에 새로운 기능을 추가할 수 있다는 점은 굿 설정파일이 급격히 복잡해 지는 것은 don’t be good
- 25. 다이내믹 프록시와 프록시 팩토리 빈
- 26. 다이내믹 프록시와 프록시 팩토리 빈 어드바이스 타깃이 필요 없는 순수한 부가기능 타깃 오브젝트에 적용하는 부가기능을 담은 오브젝트 포인트컷 부가기능 적용 대상 메서드 선정 방법 메서드 선정 알고리즘을 담은 오브젝트
- 27. 다이내믹 프록시와 프록시 팩토리 빈 포인트컷과 어드바이스를 따로 등록 하면 어떤 어드바이스에 대해 어떤 포인트컷을 적용할지 애매해지지 에 별개의 오브젝트로 묶어서 등록 어드바이스와 포인트컷을 묶은 오브 젝트를 인터페이스 이름을 따서 어 드바이저라고 부름다. 어드바이저 = 포인트컷 + 어드바이스
- 28. 다이내믹 프록시와 프록시 팩토리 빈
- 29. 자동 프록시 생성 방법과 포인트컷 트랜잭션 적용 대상이 되는 빈마다 일일이 프록시 팩토리빈을 설정 해야 한다는 문제가 있다 그것을 해결 하기 위해 스프링 컨테이너의 빈 생성 후처리 기법을 활용하여 중복 문제에 접근해 볼 수 있을것 같다.
- 30. 자동 프록시 생성 방법과 포인트 컷 DefaultAdvisorAutoProxyCreator 를 이용한 자동 프록시 생성 방법
- 31. 자동 프록시 생성 방법과 포인트컷
- 32. AOP (Aspect Oriented Programming) Aspect : 그 자체로 애플리케이션의 핵 심기능을 담고 있지는 않지만, 애플 리케이션을 구성하는 중요한 한 가 지 요소 핵심기능에 부가되어 의미를 갖는 특별 한 모듈
- 33. AOP 네임스페이스 AOP를 위해 기계적으로 적용하는 빈들을 간편한 방법으로 등록할 수 있도록 관련된 태그를 정 의해둔 aop 스키마를 제공한다. 예제 처럼 config, pointcut, advisor 세 가지 태그 를 정의해두면 그에 따라 세개의 빈이 자동으 로 등록 된다.
- 34. AOP 네임스페이스 aop 스키마 전용 태그를 사용하는 경 우 독립적인 포인트컷을 사용하는 대신 어드바이저 태그 내부에 포인 트컷을 결합하여 사용하는 방법도 가능하다.
- 35. Ref.) AOP 용어 용어 설명 타깃 타깃은 부가기능을 부여할 대상 핵심기능을 담은 클래스일 수도 있지만 경우에 따라서는 다른 부가기능을 제공하는 프록시 오브젝트일 수도 있다. 어드바이스 타깃에게 제공할 부가기능을 담은 모듈 오브젝트로 정의하기도 하지만 메소드 레벨에서 정의할 수도 있다. 조인포인트 어드방스가 적용될 수 있는 위치를 말한다. 스프링의 프록시 AOP에서 조인 포인트는 메서드의 실행 단계뿐이다. 타깃 오브젝트가 구현한 인터페이스의 모든 메서드는 조인 포인트가 된다. 포인트컷 어드바이스를 적용할 조인 포인트를 선별하는 작업 또는 그 기능을 정의한 모듈 메서드를 선정하는 기능을 갖고 있다. 프록시 클라이언트와 타깃 사이에 투명하게 존재하면서 부가기능을 제공하는 오브젝트 DI를 통해 타깃 대신 클라이언트에게 주입, 메서드 호출을 대신 받아서 타깃에 위임 그 사이에 부가 기능을 부여 어드바이저 어드바이저 = 포인트컷 + 어드바이스 어떤 부가기능(어드바이스)을 어디(포인트컷)에 전달할 것인가를 알고 있는 AOP의 가장 기본이 되는 모듈 애스펙트 AOP의 기본 모듈이다. 한 개 또는 그 이상의 포인트컷과 어드바이스의 조합으로 만들어지며 보통 싱글톤 형태의 오브젝트로 존재
- 36. Thank you!
Editor's Notes
- #4: 이슈 : 특정 트랜잭션 기술에 종속되는 코드가 돼버린다 JDBC의 로컬 트랜잭션 방식을 적용한 코드를 JTA를 이용한 글로벌/분산 트랜잭션 방식으로 바꾸려면 모든 트랜잭션 적용 코드를 수정해야한다. 장점 : 비즈니스 로직을 담당하고 있는 코드를 작성할 때는 트랜잭션과 같은 기술적이 내용에는 전혀 신경 쓰지 않아도 된다. 비즈니스 로직에대한 테스트를 손쉽게 만들어낼 수 있다.
- #5: 해결 : 트랜잭션 적용이라는 추상적인 작업 내용은 유지한 채로 구체적인 구현 방법을 자유롭게 바꿀 수 있도록 서비스 추상화 기법을 적용 비즈니스 로직 코드는 트랜잭션을 어떻게 처리해야 한다는 구체적인 방법과 서버환경에서 종속되지 않는다. 인터페이스와 DI를 통해 무엇을 하는지를 남기고, 그것을 어떻게 하는지를 분리한 것 어떻게 할지는 더 이상 비즈니스 로직 코드에는 영향을 주지 않고 독립적으로 변경할 수 있게 됐다.
- #7: UserServiceTx는 UserService 인터페이스를 구현 사용자관리라는 비즈니스 로직을 전혀 갖지 않고 고스란히 다른 UserService 구현 오브젝트에 기능을 위임 구체적인 기술은 알지 못하지만 transactionManager라는 이름의 빈으로 등록된 트랜잭션 매니저를 DI로 받아뒀다가 트랜잭션 안에서 동작하도록 만들어 줘야 하는 메서드 호출의 전과 후에 필요한 트랜잭션 경계설정 API를 사용해 주면 된다. 이코드를 보면 맨 처음 트랜잭션 처리 메서드와 비즈니스 로직 메서드를 분리했을 때 트랜잭션을 담당한 메서드와 같은 메서드가 됐다 코드를 수정했다면 이제 남은것은 빈 설정 파일을 수정하는 것이다.
- #10: 이슈 : 트랜잭션을 어떻게 다룰 것인지는 추상화를 통해서 코드에서 제거했지만 비즈니스 로직 코드에는 트랜잭션을 적용하고 있다 트랜잭션 기능을 어디에 적용할 것인가는 여전히 코드에 노출되어 있음 트랜잭션은 거의 대부분의 비즈니스 로직을 담은 메소드에 필요하다 트랜잭션 경계설정을 담당하는 코드의 특성 때문에 단순한 추상화와 메소드 추출 방법으로는 더이상 제거할 방법이 없다 해결 : 이것을 해결하기 위해 DI를 이용해 데코레이터 패턴을 적용하는 방법 클라이언트가 인터페이스와 DI를 통해 접근하도록 설계 데코레이터 패턴을 적용해서 비즈로직을 담은 클래스의 코드에는 전혀 영향을 주지 않으면서 트랜잭션을 자유롭게 부여할 수 있는 구조를 만듬 트랜잭션을 처리하는 코드는 일종의 데코레이터에 담겨 클라이언트와 비즈니스 로직을 담은 타겟 클래스 사이에 존재하도록 만듬 클라이언트가 프록시 역할을 하는 트랜잭션 데코레이터를 거쳐서 타깃에 접근할 수 있게 된다.
- #16: 이슈 : 비즈니스 로직 인터페이스의 모든 메소드마다 트랜잭션 기능을 부여하는 코드를 넣어 프록시 클래스를 만드는 작업이 오히려 큰 짐이 됐다 트랜잭션 기능을 부여하지 않아도 되는 메소드조차 프록시로서 위임 기능이 필요하기 때문에 일일이 다 구현을 해줘야 했다 해결 : 프록시 클래스 없이도 프록시 오브넥트를 런타임 시에 만들어주는 JDK 다이내믹 프록시 기술을 적용 프록시 클래스 코드 작성의 부담도 덜고부가 기능 부여 코드가 여기저기 중복돼서 나타나는 문제도 일부 해결 일부 메소드에만 트랜잭션을 적용해야 하는 경우 메소드를 선정하는 패턴 등을 이용할 수 있다 (동일한 기능의 프록시를 여러 오브젝트에 적용할 경우 오브젝트 단위로는 중복이 일어나는 문제는 해결하지 못함) JDK 다이내믹 프록시와 같은 프록시 기술을 추상화한 스프링의 프록시 팩토리 빈을 이용해서 다이내믹 프록시 생성 방법에 DI를 도입 내부적으로 템플릿/콜백 패턴을 활용하는 스프링의 프록시 팩토리 빈 덕분에 부가기능을 담은 어드바이스와 부가기능 선정 알고리즘을 담은 포인트컷은 프록시에서 분리될 수 있었고 여러 프록시에서 공유해서 사용할 수 있게 됨
- #18: 인터페이스 정의 인터페이스를 구현한 타깃 클래스 구현 인터페이스를 통해 타깃 오브젝트를 사용하는 간단한 테스트 인터페이스를 구현한 프록시 데코레이터 패턴을 적용해 부가기능 추가 업퍼케이스 위임과 기능부가라는 두가지 프록시 기능을 모두 처리하는 전형적인 프록시 클래스 프록시 적용의 일반적 문제점 두 가지를 모두 갖고 있다. 인터페이스의 모든 메서드를 구현해 위임하도록 코드를 만들어야함 부가기능이 모든 메서드에 중복돼서 나타난다
- #19: 다이내믹 프록시가 동작하는 방식 프록시 팩토리에 의해 런타임 시 다이내믹하게 만들어지는 오브젝트 다이내믹 프록시 오브젝트는 타깃의 인터페이스와 같은 타입으로 만들어진다. 클라이언트는 다이내믹 프록시 오브젝트를 타깃 인터페이스를 통해 사용할 수 있다 이 덕분에 프록시를 만들 때 인터페이스를 모두 구현해가면서 클래스를 정의하는 수고를 덜 수 있다. 프록시 팩토리에게 인터페이스 정보만 제공해 주면 해당 인터페이스를 구현한 클래스의 오브젝트를 자동으로 만들어 주기 때문 대신 프록시로서 필요한 부가기능 제공 코드는 직접 작성해야 한다. 부가기능은 프록시 오브젝트와 독립적으로 InvocationHandler 인터페이스를 구현한 오브젝트에 담는다
- #20: 인보크 메서드는 리플렉션의 메소드 인터페이스를 파라미터로 받는다 메서드를 호출할 때 전달되는 파라미터도 아그스로 받는다 클라이언트의 모든 요청을 리플렉션 정보로 변환해서 인보케이션핸들러 구현 오브젝트의 인보크 메서드로 넘기는 것 타깃 인터페이스의 모든 메서드 요청이 하나의 메서드로 집중되기 때문에 중복되는 기능을 효과적으로 제공할 수 있다. 헬로 인터페이스를 제공하면서 프록시 팩토리에게 다이내믹 프록시를 만들어달라고 요청하면 헬로 인터페이스의 모든 메소드를 구현한 오브젝트를 생성해준다 인보케이션핸들러 인터페이스를 구현한 오브젝트를 제공해주면 다이내믹 프록시가 받는 모든 요청를 인보케이션핸들러의 인보크 메서드롤 보내준다. 헬로 인터페이스의 메서드가 아무리 많아도 인보크 메서드하나로 처리할 수 있다.
- #21: 다이내믹 프록시가 클라이언트로 부터 받는 모든 요청을 인보크 메서드로 전달하고 리플렉션 에이피아이를 이용해 타깃 오브젝트의 메서드를 호출한다. 타깃 오브젝트는 생성자를 통해 미리 전달받아둔다. 타깃 오브젝트의 메서드 호출이 끝났으면 프록시가 제공하려는 부가기능인 리턴 값을 대붐자로 바꾸는 작업을 수행하고 결과를 리턴 리턴한 값은 다이내믹 프록시가 받아서 최종적으로 클라이언트에게 전달 프록시 클래스의 프록시 인스턴스 생성 방법을 보면 첫번째 파라미터로 다이내믹 프록시가 정의되는 클래스로더를 지정한다. 두번째 파라미터는 다이내믹 프록시가 구현해야할 인터페이스이다. 한번에 하나 이상의 인터페이스를 구현할 수도 있으니 인터페이스의 배열을 사용 마지막 파라미터로는 인보케이션핸들러 구현 오브젝트를 제공해얗 나다. 와 복잡하다...ㅠㅠ 이렇게 다이내믹 프록시를 적용했을 때 장점이 있긴 있는걸까? 예를 들어 인터 페이스의 메서드가 3개가 아니라 30개로 늘어나면 어떻게 될까? 인터페이스가 바뀐다면 처음 헬로업퍼케이스 처럼 클래스로 직접 구현한 프록시는 매번 코드를 추가해야 한다. 하지만 어퍼케이스핸들러와 다이내믹 프록시를 생성해서 사용한 코든 전혀 손댈것이 없다 다이내믹 프록시가 생성될때 메서드가 자동으로 포함 될것 이고 부가기능은 인보크에서 처리되기 때문이다
- #22: 유저 서비스 티엑스를 다이내믹 프록시 방식으로 변경 요청을 위임할 타깃을 DI로 제공 받는다 타깃을 저장할 변수는 오브젝트로 선언 이유는 트랜젝션이 필요한 어떤 타깃 오브젝트에도 적용하기 위해서 유저서비스티엑스와 마찬가지로 트랜잭션 추상화 인터페이스인 플랫폼트랜잭션매니저를 디아이 받는다 타깃 오브젝트의 모든 메서드에 무조건 트랜잭션이 적용되지 않도록 트랜잭션을 적용할 메서드 이름의 팬턴을 디아이 받는다. 타깃 오브젝트의 모든 메서드에 트랜잭션을 적용하는게 아니라 선별적으로 적용할 것이므로 적용할 대상을 선별하는 작업을 먼저 진행 의존성 주입을 받은 이름 패턴으로 시작되는 이름을 가진 메서드인지 확인 패턴과 일치하는 이름을 가진 메서드라면 트랜잭션을 적용하는 메서드를 호출 아니라면 부가기능 없이 타깃 오브젝트의 의 메서드를 호출해서 결과를 리턴 이제 모든 트랜젝션이 필요한 오브젝트에 적용 가능한 트랜잭션 핸들러가 만들어 졌다 이제 트랜잭션 핸들러와 다이내믹 프록시를 스프링의 DI를 통해 사용할 수 있도록 만들어 보겠다 문제는 DI 대상이 되는 다이내믹 프록시 오브젝트는 일반적인 스프링의 빈으로 등록할 방법이 없다 스프링은 내부적으로 리플렉션 API를 이용해서 빈 정의에 나오는 클래스 이름을 가지고 빈 오브젝트를 생성 다이내믹 프록시 오브젝트는 이런 식으로 프록시 오브젝트가 생성됮 않는다 클래스 자체도 내부적으로 다이내믹하게 새로 정의해서 사용하기 때문 다이내믹 프록시는 프록시 클래스의 newProxyInstance() 라는 스태틱 패토리 메소드를 통해서만 만들수 있다
- #23: proxy의 newProxyInstance() 메서드를 통해서만 생성이 가능한 다이내믹 프록시 오브젝트는 일반적인 방법으로는 스프링의 빈으로 등록할 수 없다 대신 팩토리 빈을 사용하면 다이내믹 프록시 오브젝트를 스프링의 빈으로 만들어 줄 수가 있다 스프링 빈에는 팩토리 빈과 유저서비스임플만 빈으로 등록한다. 다이내믹 프록시와 함께 생성할 트랜잭션 핸들러에게 타깃 오브젝트를 전달해줘야 하기 때문에 픽토리빈은 다이내믹 프록시기 위임할 타깃 오브젝트인 유저서비스 임플에 대한 레퍼런스를 프로퍼티를 통해 DI 받아둬야 한다.
- #26: 진짜 힘듭니다.. 지금까지 이걸 설명하려고 앞에서 추상화나...다이내믹 프록시나 팩토리빈을 설명이 길어졌습니다..ㅠㅠ 스프링에서 제공하는 방식으로 하면 깔끔하다는데… 스프링은 일관된 방법으로 프록시를 만들수 있게 도와주는 추상 레이어를 제공한다. 생성된 프록시는 빈으로 등록 돼야 하고 스프링은 프로시 오브젝트를 생성해 주는 기술을 추상화한 팩토리 빈을 제공한다. 스프링의 프록시팩토리빈은 프록시를 생성해서 빈 오브젝트로 등록하게 해주는 팩토리 빈이다. 순수하게 프록시를 생성하는 작업만을 담당하고 프록시를 통해 제공해줄 부가기능을 별도의 빈에 둘 수 있다 여기서 생성하는 프록시에서 사용할 부가기능은 메소드 인터셉터인터페이스를 구현해서 만든다
- #29: 스프링의 프록시팩토리빈은 스프링의 DI와 탬플릿/콜백패턴, 서비스 추상화 등의 기ㅓㅂ이 모두 적용된 것 그 덕분에 독립적이며, 여러 프록시가 공유할 수 있는 어드바이스와 포인트컷으로 확장 기능을 분리할 수 있었다 위에 그림은 프록시 팩토리 빈을 이용해서 많은 수의 서비스 빈에게 트랜잭션 부가기능을 적용했을 때의 구조 트랜잭션 부가 기능을 담은 트랜잭션 어드바이스는 하나만 만들어서 싱글톤 빈으로 등록해주면 DI 설정을 통해 모든 서비스에서 적용이 가능 메서드 선정 방식이 달라지는 경우만 포인트컷의 설정을 따로 등록하고 어드바이저로 조합해서 적용해주면 된다.
- #30: 이슈 : 트랜잭션 적용 대상이 되는 빈마다 일일이 프록시 팩토리 빈을 설정해줘야 한다는 부담이 남아 있다 해결 : 스프링 컨테이너의 빈 생성 후처리 기법을 활용 컨테이너 초기화 시점에서 자동으로 프록시를 만들어주는 방법을 도입 프록시를 적용할 대상을 일일이 지정하지 않고 패턴을 이용해 자동으로 선정할 수 있도록 클래스를 선정하는 기능을 담은 확장된 포인트컷을 사용 트랜잭션을 어디에 적용하는지에 대한 정보를 포인트컷이라는 독립적인 정보로 완전히 분리 처음에는 클래스와 메소드 선정 로직을 담은 코드를 직접 만들어서 포인트컷으로 사용 최종적으로는 포인트컷 표현식이라는 좀더 편리하고 깜끔한 방법을 활용해서 간단한 설정만으로 적용 대상을 손쉽게 선택
- #31: DefaulAdvisorAutoProxyCreator 빈 후처리기가 등록되어 있으면 스프링은 빈 오브젝트를 만들 때마다 후처리기에게 빈을 보낸다. 빈으로 등록된 모든 어드바이저 내의 포인트컷을 이용해 전달 받은 빈이 프록시 적용 대상인지 확인 적용 대상이면 그때는 내장된 프록시 생성기에게 현재 빈에 대한 프록시를 만들게 하고 만들어진 프록시에 어드바이저를 연결해준다. 빈 후처리기는 프록시가 생성되면 원래 컨테이너가 전달해준 빈 오브젝트 대신 프록시 오브젝트를 컨테이너에게 돌려준다. 컨테이너는 최종적으로 빈 후처리기가 돌려준 오브젝트를 빈으로 등록하고 사용한다.
- #32: 클래스 필터를 적용한 포인트컷 메서드 이름만 비교하던 포인트컷에 프로퍼티로 주어진 이름 패턴을 가지고 클래스 이름을 비교하는 ClassFilter를 추가 DefaultAd… 빈등록 기존 포인트컷 설정은 삭제하고 새로 만든 클래스 필터 지원 포인트컷을 빈으로 등록
- #33: 왼쪽 애스펙트로 부가기능을 분리하기 전의 상태 핵심기능은 깔끔하게 모듈화 되어있으나 부가기능들이 핵심기능의 모듈에 침투해 들어가면서 설계와 코드가 모두 지저분해졌다 그래서 오른쪽과 같이 핵심기능 사이에 침투한 부가기능들을 독립적인 모듈인 애스펙트로 구분해놓음 핵심 기능은 순수학 그 기능을 담은 코드로만 존재하고 애스팩트는 독립적으로 살표볼수 있게 각각 존재하게 되었다 이것과 같이 애플리케이션의 핵심적인 기능에서 부가적인 기능을 분리해서 애스팩트라는 독특한 모듈로 만들어서 설계하고 개발하는 방법을 애스펙트 지향 프로그래밍 또는 관점 지향 프로그래밍, 약자로 AOP라고 한다. AOP는 결국 애플리케이션을 다양한 측면에서 독립적으로 모델링하고, 설계하고, 개발할 수 있게 만들어 주는것