지금까지 내용으로는.. service 계층의 순수함이 유지 하게 되었고.. repository 계층에서는.. JDBC를 사용하기에.. 다른 메서드 임에도.. 동일한 반복코드가 많다.. 이를 해결해보자. 반복코드 1. 커넥션 조회, 커넥션 동기화 2. preparedStatement 생성 및 파라미터 바인딩 3. 쿼리 실행 4. 결과 바인딩 5. 예외 발생 시, 스프링 예외 변환기 실행 6. 리소스 종료 템플릿 콜백 패턴으로 해결 JdbcTemplate JdbcTemplate을 사용하면.. 위 반복코드가 대부분 사라지며, 커넥션 동기화, 스프링 예외 변환기도 자동으로 실행 해준다. 기본적으로 SQL Mapper 방식이다.

직전 포스팅에서 repository layer에 특정 DB에 종속적인 코드가 들어가 버렸다. e.getErrorCode() == 23505 해당 코드는 H2 한정이다.. 지금까지 특정 DB에 따른 코드 분리는 필요 없었지만.. DataSource가 라이브러리에 등록된 DB 드라이버, DB접근 URL 및 부가정보(이름, 비밀번호 등)로 알아서 커넥션 획득해줬기 때문.. 예외처리 때문에 코드 분리를 하거나.. 코드가 지저분해질 위기에 처했다. 해결.. 스프링은 이미 모든 DB에러 상황에 맞는 예외를 만들어 놨으며.. -> 스프링 데이터 접근 예외(DataAccessException) 계층 DB에 따른 error code들을 매핑하여, 동일한 원인일 경우 일관된 예외로 변환 가능하다. -> 스프링 예외 변환기..

복구가 가능한 예외는 어떻게 처리하면 좋을까.. 예를 들어서.. 키값이 중복이라 DB에서 예외를 던지는 경우를 생각해보자.. 개발자는 이를 애플리케이션 로직상 해결할 수 있다. (기존 키값에서 +1 정도로 해결하는 사양일 경우) DB에서는 SQLException을 발생시키고 던진다. 개발자는 중복 키에 의한 예외인 것을.. e.getErrorCode() 로 알 수 있다. 중복 키 처리에 대한 로직은 서비스 계층에 들어가야 하는데... 이를 처리하는 조건문을 위해 서비스 계층에 SQLException을 던지면 .. 또.. OCP 위반이다. 아래 방법을 참고 하자. repository에서 해결해보자.. repository 구현체 코드 중 일부이다. DB에서 발생된 SQLException 예외 중, 중복 ke..

https://starryeye.tistory.com/52 [Java 정리] 예외 Java의 예외에 대해 알아보자. java의 예외도 객체이다. 따라서 상속 구조를 가지며, 계층이 존재한다. Java 예외 계층 Throwable 최상위 예외이며 Object를 상속 받고있다. 개발자는 Throwable 예외를 catch starryeye.tistory.com 위 포스팅을 읽고 시작하자.. 지금까지의 포스팅에서 repository 구현체 layer 에서 사용할 DB를 연동하고.. 의존성을 가지는 것으로 볼 수 있다. 다음 두가지 문제에 대해 포스팅 하겠다. 1. 복구 불가능한 예외 2. 의존 관계에 대한 문제 복구 불가능한 예외 DB에서 발생하는 대부분의 예외는 처리가 불가능하다. SQLException을 ..

Java의 예외에 대해 알아보자. java의 예외도 객체이다. 따라서 상속 구조를 가지며, 계층이 존재한다. Java 예외 계층 Throwable 최상위 예외이며 Object를 상속 받고있다. 개발자는 Throwable 예외를 catch로 잡으려고 하면 안된다. -> 최상위 예외를 잡으면 그 하위 예외도 같이 잡힌다. -> 아래의 Error 예외도 같이 잡히기 때문이다. Error 언체크 예외이다. 애플리케이션에서 복구 불가능한 시스템 예외이다. 따라서 개발자는 Error 예외를 catch로 잡으려고 하면 안된다. Exception 체크 예외이다. Exception 예외와 하위 예외는 "컴파일러가 체크"하는 체크 예외이다. (아래의 RuntimeException은 컴파일러가 잡지 않는다.) Runtime..

TransactionTemplate 템플릿 콜백 패턴을 사용하여 서비스 계층에서 Transaction을 사용함에 있어서 메서드마다 등장하는 코드를 줄일 수 있다. (repository 계층의 메서드 성공여부 try-catch에 따른 commit, rollback 코드가 없어짐) 하지만.. 서비스 계층에 비즈니스 로직만 순수하게 있는 상황은 아니다. 트랜잭션 AOP (선언적 트랜잭션 관리) 서비스 계층에 순수 비즈니스 로직만 남길 수 있다. @Transactional 어노테이션만 써주고.. 해당 비즈니스 로직만 구현하면 된다.. (스프링 부트에서 제공하기에.. 스프링 부트 종속성이 생김) 아래는 스프링이 트랜잭션 AOP를 적용하기 위해 스프링 컨테이너에 자동으로 등록하는 빈이다. 어드바이저 : BeanFa..

스프링 부트가 기본으로 제공하는(등록하는) ExceptionResolver에 대해 계속 알아보자.. 1. ExceptionHandlerExceptionResolver : @ExceptionHandler 처리 2. ResponseStatusExceptionResolver : Http 상태코드 지정할 수 있는 @ResponseStatus 처리 3. DefaultHandlerExceptionResolver : 스프링 내부 기본 예외 처리 위 순서대로 우선순위가 있다. (1번 return null이면 다음 ExceptionResolver인 2번이 호출되는 식) 이번엔.. 첫번째 우선순위를 가진.. ExceptionHandlerExceptionResolver에 대해 알아보자. BasicErrorController..

스프링 부트가 기본으로 제공하는(등록하는) ExceptionResolver에 대해 계속 알아보자.. 1. ExceptionHandlerExceptionResolver : @ExceptionHandler 처리 2. ResponseStatusExceptionResolver : Http 상태코드 지정할 수 있는 @ResponseStatus 처리 3. DefaultHandlerExceptionResolver : 스프링 내부 기본 예외 처리 위 순서대로 우선순위가 있다. (1번 return null이면 다음 ExceptionResolver인 2번이 호출되는 식) 이번엔.. DefaultHandlerExceptionResolver에 대해 알아보자. 스프링 내부에서 발생되는 예외를 해결해준다. BindingResul..