[스프링 DB 1편] - 7. 스프링과 문제 해결 - 트랜잭션

 

 

애플리케이션 구조

 

시간이 흘러서 UI(웹)와 관련된 부분이 변하고, 데이터 저장 기술을 다른 기술로 변경해도,

 

비즈니스 로직은 최대한 변경없이 유지되어야 한다.

이렇게 하려면 서비스 계층을 특정 기술에 종속적이지 않게 개발해야 한다.

 

이렇게 계층을 나눈 이유도 서비스 계층을 최대한 순수하게 유지하기 위한 목적이 크다.

 

 

 

예를 들어서 JDBC를 사용하다가 JPA 로 변경해도 서비스 계층은 변경하지 않아도 된다.

 

물론 서비스 계층에서 데이터 접근 계층을 직접 접근하는 것이 아니라,

 

인터페이스를 제공하고 서비스 계층은 이 인터페이스에 의존하는 것이 좋다.

 

그래야 서비스 코드의 변경 없이 JdbcRepository 를 JpaRepository 로 변경할 수 있다.

 

 

 

정리하자면 서비스 계층은 가급적 비즈니스 로직만 구현하고 특정 구현 기술에 직접 의존해서는 안된다.

 

이렇게 하면 향후 구현 기술이 변경될 때 변경의 영향 범위를 최소화 할 수 있다.

 

 

 

 

트랜잭션을 적용한 MemberServiceV2 코드

public void accountTransfer(String fromId, String toId, int money) throws
        SQLException {
    Connection con = dataSource.getConnection();
    try {
        con.setAutoCommit(false); //트랜잭션 시작 //비즈니스 로직
        bizLogic(con, fromId, toId, money); con.commit(); //성공시 커밋
    } catch (Exception e) { con.rollback(); //실패시 롤백
        throw new IllegalStateException(e);
    } finally {
        release(con);
    }
}

 

문제점들

 

javax.sql.DataSource , java.sql.Connection , java.sql.SQLException 

 

트랜잭션을 사용하기 위해 JDBC 기술에 의존한다.

 

결과적으로 비즈니스 로직보다 JDBC를 사용해서 트랜잭션을 처리하는 코드가 더 많다.

 

같은 트랜잭션을 유지하기 위해 커넥션을 파라미터로 넘겨야 한다.

 

유사한 코드의 반복이 너무 많다.  /   try , catch , finally ...

 

 

 

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

 

 

 

 

트랜잭션 추상화