체크 예외와 인터페이스 서비스 계층은 가급적 특정 구현 기술에 의존하지 않고, 순수하게 유지하는 것이 좋다. 이렇게 하려면 예외에 대한 의존도 함께 해결해야한다. 예를 들어서 서비스가 처리할 수 없는 SQLException 에 대한 의존을 제거하려면 어떻게 해야할까? 서비스가 처리할 수 없으므로 리포지토리가 던지는 SQLException 체크 예외를 런타임 예외로 전환해서 서비스 계층에 던지자. 이렇게 하면 서비스 계층이 해당 예외를 무시할 수 있기 때문에, 특정 구현 기술에 의존하는 부분을 제거하고 서비스 계층을 순수하게 유지할 수 있다. 체크 예외 코드에 인터페이스 도입 public class MemberRepositoryV3 implements MemberRepositoryEx { public Me..

체크 예외 활용 기본 원칙은 다음 2가지를 기억하자. 1. 기본적으로 언체크(런타임) 예외를 사용하자. 2. 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용하자. 이 경우 해당 예외를 잡아서 반드시 처리해야 하는 문제일 때만 체크 예외를 사용해야 한다. 예를 들어서 다음과 같은 경우가 있다. 체크 예외 예) 계좌 이체 실패 예외 결제시 포인트 부족 예외 로그인 ID, PW 불일치 예외 물론 이 경우에도 100% 체크 예외로 만들어야 하는 것은 아니다. 다만 계좌 이체 실패처럼 매우 심각한 문제는 개발자가 실수로 예외를 놓치면 안된다고 판단할 수 있다. 이 경우 체크 예외로 만들어 두면 컴파일러를 통해 놓친 예외를 인지할 수 있다. 체크 예외의 문제점 체크 예외는 컴파일러가 예외 누락을 체크해..

예외(Exception) 자바에서 예외(Exception)는 프로그램 실행 중 발생할 수 있는 예상치 못한 상황 또는 오류를 나타냅니다. 이러한 예외는 프로그램 실행 도중 발생할 수 있으며, 발생 시 예외 처리를 해주어야 합니다. Throwable 최상위 예외 , 예외(Exception)와 에러(Error)를 모두 포함하는 클래스입니다. 에러(Error) 메모리 부족이나 심각한 시스템 오류와 같이 애플리케이션에서 복구 불가능한 시스템 예외이다. 애플리케이션 개발자는 이 예외를 잡으려고 해서는 안된다. 예외(Exception) 예외는 크게 두 가지 종류로 나뉘며, 각각 checked 예외와 unchecked 예외로 구분됩니다. Checked 예외는 RuntimeException 클래스를 상속하지 않는 예외..

스프링 부트가 등장하기 이전에는 데이터소스와 트랜잭션 매니저를 개발자가 직접 스프링 빈으로 등록해서 사용했다. @Bean DataSource dataSource() { return new DriverManagerDataSource(URL, USERNAME, PASSWORD); } @Bean PlatformTransactionManager transactionManager() { return new DataSourceTransactionManager(dataSource()); } 데이터소스와 트랜잭션 매니저를 직접 스프링 빈으로 등록 스프링 부트가 나오면서 많은 부분이 자동화되었다. 데이터소스(DataSource) - 자동 등록 스프링 부트는 데이터소스( DataSource )를 스프링 빈에 자동으로 등록..

트랜잭션 AOP 이해 지금까지 트랜잭션을 편리하게 처리하기 위해서 트랜잭션 추상화도 도입하고, 추가로 반복적인 트랜잭션 로직을 해결하기 위해 트랜잭션 템플릿도 도입했다. 트랜잭션 템플릿 덕분에 트랜잭션을 처리하는 반복 코드는 해결할 수 있었다. 하지만 서비스 계층에 순수한 비즈니스 로직만 남긴다는 목표는 아직 달성하지 못했다. 이럴 때 스프링 AOP를 통해 프록시를 도입하면 문제를 깔끔하게 해결할 수 있다. 참고 ) 지금은 @Transactional 을 사용하면 스프링이 AOP를 사용해서 트랜잭션을 편리하게 처리해준다 정도로 이해해도 된다. 프록시를 통한 문제 해결 프록시 도입 전 프록시를 도입하기 전에는 기존처럼 서비스의 로직에서 트랜잭션을 직접 시작한다. 서비스에 비즈니스 로직과 트랜잭션 처리 로직이..

트랜잭션 사용 코드 //트랜잭션 시작 TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition()); try { //비즈니스 로직 bizLogic(fromId, toId, money); transactionManager.commit(status); //성공시 커밋 } catch (Exception e) { transactionManager.rollback(status); //실패시 롤백 throw new IllegalStateException(e); } 트랜잭션을 사용하는 로직을 살펴보면 다음과 같은 패턴이 반복되는 것을 확인할 수 있다. 이런 형태는 각각의 서비스에서 반복된다. 달라지는 부분은..

트랜잭션 추상화 구현 기술마다 트랜잭션을 사용하는 방법이 다르다. JDBC : con.setAutoCommit(false) JPA : transaction.begin() 향후 JDBC에서 JPA 같은 다른 데이터 접근 기술로 변경하면, 서비스 계층의 트랜잭션 관련 코드도 모두 함께 수정해야 한다. 이 문제를 해결하려면 트랜잭션 기능을 추상화하면 된다. 트랜잭션 추상화 인터페이스 public interface TxManager { begin(); commit(); rollback(); } TxManager 인터페이스를 기반으로 각각의 기술에 맞는 구현체를 만들면 된다. JdbcTxManager : JDBC 트랜잭션 기능을 제공하는 구현체 JpaTxManager : JPA 트랜잭션 기능을 제공하는 구현체 트..

애플리케이션 구조 시간이 흘러서 UI(웹)와 관련된 부분이 변하고, 데이터 저장 기술을 다른 기술로 변경해도, 비즈니스 로직은 최대한 변경없이 유지되어야 한다. 이렇게 하려면 서비스 계층을 특정 기술에 종속적이지 않게 개발해야 한다. 이렇게 계층을 나눈 이유도 서비스 계층을 최대한 순수하게 유지하기 위한 목적이 크다. 예를 들어서 JDBC를 사용하다가 JPA 로 변경해도 서비스 계층은 변경하지 않아도 된다. 물론 서비스 계층에서 데이터 접근 계층을 직접 접근하는 것이 아니라, 인터페이스를 제공하고 서비스 계층은 이 인터페이스에 의존하는 것이 좋다. 그래야 서비스 코드의 변경 없이 JdbcRepository 를 JpaRepository 로 변경할 수 있다. 정리하자면 서비스 계층은 가급적 비즈니스 로직만 ..