• 스프링에 적용된 가장 인기 있는 AOP의 적용 대상 → 선언적 트랜잭션 기능

6.1 트랜잭션 코드의 분리

1. 메소드 분리

• 트랜잭션이 적용된 코드를 보면 비즈니스 로직 코드를 사이에 두고 트랜잭션 시작과 종료를 담당하는 코드가 앞뒤에 위치
• upgradeLevels()에서 트랜잭션 경계설정의 코드와 비즈니스 로직 코드 간에 서로 주고받는 정보가 없다
• 성격이 다른 코드를 두 개의 메소드로 분리

2. DI를 이용한 클래스의 분리

• UserService의 트랜잭션 코드를 클래스 밖으로 뽑아내기

1) DI 적용을 이용한 트랜잭션 분리

• 인터페이스를 이용해 구현 클래스를 클라이언트에 노출하지 않고 런타임 시에 DI를 통해 적용하는 방법을 쓰는 이유 : 일반적으로 구현 클래스를 바꿔가면서 사용하기 위해 → 꼭 그래야 한다는 제약은 없음
• (405p 그림 6-3) : UserService를 구현한 또 다른 구현 클래스를 만듬 → UserServiceimpl을 대신하기 위해 만든 게 아니라 트랜잭션의 경계설정 책임만 맡고있음

2) UserService 인터페이스 도입

• 클라이언트가 사용할 로직을 담은 핵심 메소드만 UserService 인터페이스로 만든 후 UserServiceImpl이 구현하도록 만듬

3) 분리된 트랜잭션 기능

• 비즈니스 트랜잭션 처리를 담은 UserServiceTx를 만듬