공부한것들을 정리하는 블로그 입니다.
토비의스프링3.1 6장. AOP 본문
토비의스프링 6장. AOP
6.1 트랜잭션 코드의 분리
메서드 분리하기
- 트랜잭션의 경계를 설정하는 코드와 비즈니스 로직을 구분할 수 있다.
- 그러나 트랜잭션 코드가 여전히 UserService 내부에 존재하는 것이 부담이다.
DI를 이용해 트랜잭션 분리하기
- 현재 구현은 클라이언트가 UserService 클래스를 직접 참조하고 있다. 그래서 인터페이스에 의존하여 결합도를 낮추는 작업을 수행한다.
- 지금 해결하고자 하는 문제는 비즈니스 로직을 담고 있는 코드와 트랜잭션 담당하는 코드를 분리하기 위함이다.
- 그러기 위해 UserService를 구현한 UserServiceTx 클래스를 만든다.
- 주입받는 UserService는 비즈니스 로직을 처리하는 구체 클래스고,
- UserServiceTx는 트랜잭션만을 담당한다.
- Client → UserServiceTx(트랜잭션 경계 설정) → UserService(비즈니스 로직)
테스트 수정하기 : @Autowired
트랜잭션 경계설정 코드 분리의 장점
- 비즈니스 로직을 담당하는 UserServiceImpl 코드 작성시 트랜잭션에 대한 고민은 하지 않아도 된다.
- 비즈니스 로직 테스트를 좀 더 쉽게 작성할 수 있다.
6.2 고립된 단위 테스트
테스트를 가장 쉽게 하는 방법은 가능한 작은 단위로 쪼개는 것이다. 테스트 실패 시 원인을 찾기 쉽기 때문이다. 하지만 작은 단위의 테스트를 작성하는게 항상 가능한 것은 아니다.
단위 테스트와 통합 테스트
목 프레임워크
Mockito 프레임워크
6.3 다이나믹 프록시와 팩토리 빈
일반적인 전략 패턴으로 특정 구현을 분리할 때, 원래 코드에는 '해당 기능을 위임하는' 코드가 있어야 한다. 구체적인 구현은 드러나지 않을 지라도, 위임 코드를 포함하여야 한다.
- UserServiceTx를 통해 트랜잭션 코드를 위임하는 흔적도 남기지 않고 UserServiceImpl에서 분리할 수 있었다. 그러나 여전히 문제가 남아있다.
- 만약 핵심기능을 가진 클래스(UserServiceImpl)를 클라이언트에서 직접 호출한다면, 부가 기능(UserServiceTx)이 작동하지 않는다.
이렇게 클라이언트가 사용하려고 하는 실제 대상(주요 비즈니스 로직)인 것 처럼 위장해 클라이언트의 요청을 받는 패턴을 프록시 패턴이라고 한다. 이 프록시를 거쳐 최종적으로 요청을 처리하는 실제 오브젝트를 타겟 혹은 실체(real subject)라고 부른다.
프록시 패턴의 사용이유
- 클라이언트가 타겟에 접근하는 방법을 제어하기 위함이다.
- 타겟에 부가적인 기능을 부여하기 위해 쓴다.
데코레이터 패턴
- 타겟에 부가적인 기능을 런타임에 다이나믹하게 부여하기 위한 프록시를 사용하는 패턴이다.
프록시 패턴
- 타겟의 접근 방법을 제어하려는 목적을 가지고 프록시를 사용하는 패턴이다. 기능의 확장이나 추가의 역할을 하지 않지만, 클라이언트가 접근하는 방식을 변경한다.
다이나믹 프록시 : 직접 만든 프록시보다 좋은 점은 인터페이스의 메서드가 늘어나도 추가적인 구현이 필요없다.
- 다이나믹 프록시 적용
- 다이나믹 프록시로 트랜잭션 설정 구현하기
- 다이나믹 프록시를 위한 팩토리 빈
6.4 스프링의 프록시 팩토리 빈
6.5 스프링 AOP
비즈니스 로직에 반복적으로 등장해야 했던 트랜잭션 코드를 분리
AOP 살펴보기
- 부가기능의 모듈화는 전통적인 객체지향에서 성취하기 어려웠기에, 자연어 대신 기계어로 사고하는 컴퓨터과학의 아버지들이 연구하여 성취하였다. 객체지향 패러다임과 부가기능은 구분되는 특성이 있다고 보았기에 부가기능 모듈을 Aspect라고 부르게 되었다.
- 부가 기능을 핵심 기능에서 분리하여 Aspect라는 모듈로 설계하고 개발하는 방법을 AOP라고 부른다. 핵심 기능은 OOP로 구현하고, 부가 기능은 AOP 원칙 아래서 구현함으로써 핵심 기능이 OOP 원칙을 훼손하지 않도록 보조한다.
스프링 AOP vs AspectJ AOP
- 스프링은 IoC/DI 컨테이너 + 다이나믹 프록시 + 데코레이터/프록시 + 자동 프록시 생성기법 + 빈 오브젝트 후처리 등 코드레벨의 기술과 패턴 등을 이용하여 구현한 프록시 방식의 AOP이다. 자바 JDK와 스프링 컨테이너만을 이용하여 컴팩트하게 이용할 수 있다는 장점이 있다.
- 반면에 AspectJ AOP는 부가 기능이 적용될 타겟 오브젝트의 컴파일된 클래스 파일을 수정하거나, 클래스가 JVM에 로딩되는 시점의 바이트코드를 조작하여 AOP를 구현한다.
6.6 트랜잭션 속성
6.7 애너테이션 기반의 트랜잭션 속성과 포인트컷
클래스나 메서드에 따라 세밀하게 정의된 트랜잭션 속성을 적용하고 싶을 경우 애너테이션을 지정하는 방법이 있다.
@Transactional
- TransactionInterceptor는 패턴을 통해 부여되는 트랜잭션 속성정보를 무시하고,
- TransactionAttributeSourcePointcut을 통해 타겟 오브젝트를 선정한다.
- 애너테이션에서 트랜잭션 속성을 가져오는 AnnotationTransactionAttributeSource를 사용한다.
6.8 트랜잭션 지원 테스트
@Transactional 애너테이션
'Spring > 공부' 카테고리의 다른 글
토비의스프링3.1 2권 1장. IoC 컨테이너와 DI (0) | 2022.08.02 |
---|---|
토비의스프링3.1 9장. 스프링 프로젝트 시작하기 (0) | 2022.08.02 |
토비의스프링3.1 8장. 스프링이란 무엇인가 (0) | 2022.07.30 |
토비의스프링3.1 7장. 스프링 핵심 기술의 응용 (0) | 2022.07.26 |
토비의스프링3.1 5장. 서비스 추상화 (0) | 2022.07.23 |
토비의스프링3.1 4장. 예외 (0) | 2022.07.19 |
토비의스프링3.1 3장. 템플릿 (0) | 2022.07.19 |
토비의스프링3.1 2장. 테스트 (0) | 2022.07.19 |