23. 트랜잭션 추상화

스프링은 서비스 계층을 순수하게 유지하면서, 앞서 말했던 문제들을 해결 할 수 있는 다양한 방법과 기술들을 제공한다.

 

 

먼저, 앞서 Service는 Jdbc 기술에 의존하고 있었다.

만약 Jpa로 바꾸게 된다면, Jpa의 트랜잭션 구현은 비슷한 면도 있지만 다르다.

 

만약 기술을 바꿀 때 마다..

리포지토리는 사실 DB와의 소통을 위한 것 이라 적어도 명분은 되지만,

비즈니스 로직은 아니다.. 정말 순수해야 한다.

 

DB 접근 기술에 따라 서비스 로직도 바꿔야 한다면, 

리포지토리의 단일책임 원칙에 맞지 않는 것이다.

 

해결법 중에 이제, 

트랜잭션 인터페이스를 만들고, 트랜잭션은 외부에서 주입받거나, 어댑터 패턴으로 처리하고 하면 되긴 할 듯 싶다.(확실히 이번 경우는 서버사이드에서 바뀌는 거니 어댑터 패턴은 아니고 외부 주입이 맞을 듯. 요청은 여러 요청이 있을 수 있지만, DB접근 기술은 보통 한번에 하나만.. 쓰니까.)

 

트랜잭션은 간단하기는 하다.

public interface TxManager{

    bigin();

    commit();

    rollback();

    close();

}

 

이 정도 일 듯 싶다.

 

 

물론 우릭가 직접 구현해도 되지만,

이미 스프링에서 제공해 주는 것이 있다.

 

구현체도 각 회사마다 구현해 놓은 듯 하다.

 

public interface PlatformTransactionManager extends TransactionManager {
	TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;

	void commit(TransactionStatus status) throws TransactionException;

	void rollback(TransactionStatus status) throws TransactionException;
}

실제 PlatformTransactionManager 인터페이스이다.

 

getTransaction이 트랜잭션 시작하는 부분이다.

시작이 getTransaction인 이유는 이미 트랜잭션 사용중인 경우 해당 트랜잭션에 참여할 수 있도록 할 수 있기 때문에. 트랜잭션을 얻어온다 뭐 그런 의미인듯.

 

아니더라도 새롭게 트랜잭션을 얻어온다는 뜻.