- IoC/DI, 서비스 추상화와 더불어 스프링의 3대 기반기술의 하나
- 가장 인기있는 AOP의 적용대상은 선언적 트랜잭션 기능이다.
< 트랜잭션 코드의 분리 >
메서드 분리
- 비지니스 로직과 트랜잭션 코드가 서로 주고받는 정보가 없을 경우
트랜잭션 경계설정 사이의 비지니스 코드를 메서드로 분리
DI를 이용한 클래스의 분리
- DI의 기본 아이디어는 실제 사용할 오브젝트의 클래스 정체는 감춘 채
인터페이스를 통해 간접으로 접근하게 하는 것.
- Service에 순수하게 비지니스 로직만 두고 트랜잭션 경계설정을 담당하는 코드를 외부로 빼내야 한다.
ex)
UserService 인터페이스를 만들고UserServiceImpl 클래스에 비지니스로직을 넣고
PlatformTranscationManager 빈으로 등록된 트랜잭션 매니저를 DI로 받는
즉, 트랜잭션 경계설정 코드의 분리와 DI를 통한 연결
장점
1. 비지니스 로직 담당 UserServiceImpl은 트랜잭션에 신경안써도 됨
2. 비지니스 로직에 대한 테스트가 쉽다.
< 고립된 단위 테스트 >
단위테스트
- 단위는 정하기 나름
- 하나의 단위에 초점을 맞춘 테스트
- 목 오브젝트 등의 테스트 대역을 이용해
의존 오브젝트나 외부의 리소스를 사용하지 않도록 고립시켜서 테스트 하는 것
통합테스트
- 두 개 이상의 성격이나 계층이 다른 오브젝트가 연동하도록 만들어 테스트하거나,
외부의 DB나 파일, 서비스 등의리소스가 참여하는 테스트
- 두 개 이상의 단위가 결합해서 동작하면서 테스트가 수행되는 것
< 다이내믹 프록시와 팩토리 빈 >
프록시와 프록시 패턴, 데코레이터 패턴
프록시
- 자신이 클라이언트가 사용하려고 하는 실제 대상인 것처럼 위장해서
클라이언트의 요청을 받아주는 것을 대리자, 대리인과 같은 역할을 한다
- 그리고 프록시를 통해 최종적으로 요청을 위임받아 처리하는 실제 오브젝트를 타깃, 실체라고 한다.
클라이언트 -> 프록시 -> 타깃
사용목적
1. 클라이언트가 타깃에 접근하는 방법을 제어하기 위해
2. 타깃에 부가적인 기능을 부여해주기 위해
프록시의 사용 목적에 따라 2가지 패턴으로 분리된다.
데코레이터 패턴
- 타깃에 부가적인 기능을 런타임 시 다이나믹하게 부여해주기 위해 프록시를 사용하는 패턴
다이나믹하게 부여?
컴파일 시점, 즉 코드상에는 프록시와 타깃이 어떻게 연결되어 사용되는지 정해져 있지 않다는 뜻
- 데코레이터 패턴의 이름처럼 실제 내용물은 동일하지만 부가적인 효과를 부여해준다.
- 인터페이스를 통해 위임하는 방식
프록시 패턴
프록시와 프록시 패턴은 다르다
프록시
- 클라이언트와 사용 대상 사이에 대리 역할을 맡은 오브젝트
프록시패턴
- 타깃에 대한 접근 방법을 제어하려는 목적
- 타깃 오브젝트는 꼭 필요한 시점까지 생성하지 않는 편이 좋지만
타깃 오브젝트에 대한 레퍼런스가 미리 필요할 수 있을 때 사용
- 클라이언트에게 타깃에 대한 레퍼런스 대신 프록시를 넘겨주는 것
- 타깃의 기능 자체에는 관여하지 않으면서접근하는 방법을 제어
ex) 프록시패턴과 데코레이터 패턴의 혼용
클라이언트 -> 접근제어 프록시(프록시패턴) ->
컬러 데코레이터(데코레이터패턴) -> 페이징 데코레이터(데코레이터패턴) -> 소스출력기능(타깃)
- 정리
타깃과 동일한 인터페이스를 구현하고, 클라이언트와 타깃 사에에 존재하면서,
기능의 부가 또는 접근 제어를 담당하는 오브젝트를 모두 프록시라 부른다.
프록시 사용 목적이
기능의 부가이면 데코레이터패턴,
접근 제어이면 프록시 패턴
다이내믹 프록시
프록시는 기존코드에 영향을 주지 않고, 타깃의 기능을 확장하거나 접근방법을 제어하는 유용한 방법이다.
프록시의 구성과 프록시 작성의 문제점
1. 타깃의 인터페이스를 구현하고 위임하는 코드 작성이 번거로움
- 부가기능이 필요없는 메서드도 구현해서 타깃으로 위임하는 코드를 일일이 만들어야 함
- 인터페이스의 메서드가 많아진다.
- 타깃인터페이스의 메서드가 추가,변경 될 때마다 함께 수정필요
2. 부가기능 코드가 중복될 가능성이 많음ㄷ
! 이런 문제를 해결하는게 JDK의 다이내믹 프록시 !
다이내믹 프록시는 리플랙션 기능을 이용해 프록시를 만들어줌
팩토리 빈
- 스프링을 대신해서 오브젝트의 생성로직을 담당하도록 만들어진 특별한 빈
- FactoryBean이라는 인터페이스를 구현
449p 부터 555페이지까지 일단 생략.
추후 다시 보겠다. 아직 이해가 전혀 안가서 정리도 못하겠다
'책 > 토비 스프링 2020' 카테고리의 다른 글
(토비의 스프링) 5. 서비스 추상화 (0) | 2019.12.24 |
---|---|
(토비의 스프링) 4. 예외 (0) | 2019.12.20 |
(토비의 스프링) 3. 템플릿 (0) | 2019.12.19 |
(토비의 스프링) 2. 테스트 (JUnit) (0) | 2019.12.19 |
(토비의 스프링) 1. 오브젝트와 의존관계 (IoC/DI ) (0) | 2019.12.18 |