여전히 트랜잭션을 담당하는 기술적인 코드가 UserService 안에 자리잡고 있다.

• 서로 주고받는 정보가 없다? → 트랜잭션 코드가 존재하지 않는 것처럼 사라지게 할 수는 없나?
• 트랜잭션 코드를 클래스 밖으로 뽑아내자
  • UserService 에서 보이지 않도록

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

UserService 는 UserServiceTest 가 클라이언트가 되어 사용하고 있다.

• 실전에서는 다른 클래스나 모듈에서 UserService 를 호출해 사용할 것
• UserService 는 현재 클래스로 되어 있으니 다른 코드에서 사용한다면 UserService 클래스를 직접 참조하게 된다.
  • UserService 클래스를 직접 사용하는 클라이언트 코드는 트랜잭션 기능이 빠진 UserService 를 사용하게 될 것
  • 구체적인 구현 클래스를 직접 참조하는 경우의 전형적인 단점

직접 사용이 문제? 간접적으로 사용하자.

• DI 의 기본 아이디어
  • 실제 사용할 오브젝트의 클래스 정체는 감춘 채 인터페이스를 통해 간접으로 접근하기
  • ⇒ 구현 클래스는 언제든 외부에서 변경 가능
• 현재 구조

1. UserService 를 인터페이스로 만든다.
2. 기존 코드는 UserService 인터페이스의 구현 클래스를 만들어 넣도록 하자.

• 그 결과 얻을 효과

  • 클라이언트와 결합이 약해진다.
  • 직접 구현 클래스에 의존하지 않아 유연한 확장이 가능하다.
  • 인터페이스를 이용해 클라이언트와 UserService 구현 클래스의 직접 결합을 막고 유연한 확장이 가능하다.

  

• 인터페이스 이용 → 구현클래스를 클라이언트로부터 감추고 런타임 시 DI 적용하는 방법

  • 사용하는 이유: 구현 클래스를 바꿔가며 사용하기 위해
  • 현재는 한번에 한 가지 클래스를 선택해서 적용 → 반드시 그래야 할 제약은 없음
    • 테스트 → 테스트 구현 클래스 DI
    • 정식 운영 → 정규 구현 클래스 DI

문제 상황

• UserService 에 순수하게 비즈니스 로직을 담는 코드만 두고 트랜잭션 경계 설정 담당 코드는 외부로 분리