JDBC를 사용한 데이터 접근 기술은 크게 3가지로 나뉜다. 1. JDBC를 직접 사용 2. SQL Mapper 3. ORM 기술 JDBC를 직접 사용 말 그대로 개발자가 직접 JDBC 표준 인터페이스를 사용하며 모든 것을 컨트롤한다.. SQL Mapper SQL Mapper 내부에서 JDBC를 사용한다. (JDBC를 편리하게 사용할 수 있도록 JDBC를 감싼 기술이다.) 개발자는 SQL Mapper 사용법만 알면 조금 더 편리하게 JDBC를 사용할 수 있게 된다. 개발자는 SQL을 직접 작성해야한다. JDBC의 반복코드를 작성할 필요가 없다. 응답 결과는 객체로 자동 변환 해준다. ex. 스프링 JdbcTemplate, MyBatis ORM 기술 객체를 RDBMS의 테이블과 매핑 시켜줌 그래서 개발자가..

JDBC 이해 애플리케이션을 개발할 때.. 중요한 데이터는 대부분 데이터 베이스에 보관한다. 그래서.. 애플리케이션은 DB에 접근하여.. 저장, 조회 등을 하게된다. 이때.. 애플리케이션은 DB와 다음 과정을 거친다. 1. 커넥션 연결 : 주로 TCP/IP를 사용하여 연결 2. SQL 전달 : 연결된 커넥션을 통해 DB가 이해 할 수 있는 SQL을 전달 3. 결과 응답 : DB는 전달된 SQL을 수행하고 그 결과를 애플리케이션에 리턴 하지만... DB의 종류는 매우 많다.. 그리고 종류별로 방법이 모두 다르다.. -> DB가 바뀌면 애플리케이션의 코드를 모두 바꿔줘야 하며.. 새로 학습해야함.. 이런 문제를 해결하기 위해 JDBC(Java DataBase Connectivity) 등장! (DB 접근 자바..

스프링 부트가 기본으로 제공하는(등록하는) 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..

이전 포스팅까지... HandlerExceptionResolver를 직접 상속받으며 활용하는 방법을 알아봤다.. -> 개발량도 많고 개발하기에 불편한 점이 많았다.. 이러한 문제를 해결해주는.. 스프링 부트가 기본으로 제공하는(등록하는) ExceptionResolver에 대해 알아보자.. 1. ExceptionHandlerExceptionResolver : @ExceptionHandler 처리 2. ResponseStatusExceptionResolver : Http 상태코드 지정할 수 있는 @ResponseStatus 처리 3. DefaultHandlerExceptionResolver : 스프링 내부 기본 예외 처리 위 순서대로 우선순위가 있다. (1번 return null이면 다음 ExceptionR..

예외처리 6번 포스팅에서는 일반적인 예외가 발생했을때 HandlerExceptionResolver를 활용하여 sendError로 정상 리턴되면서 WAS가 알아볼 수 있도록 새로운 예외를 만들어주고 상태코드를 변경해줄 수 있었다. 또한, HttpServletResponse 파라미터를 활용하여 응답을 직접 구성해줘서 그대로 응답으로 내려주는 가능성도 보인다. 코드로 알아보자.. 개발자가 UserException이라는 새로운 예외를 만들었고 해당 예외를 처리 해줄 수 있는 HandlerExceptionResolver를 구현하였다. 해당 예외가 발생했다면 응답 상태코드로 400을 내려주도록 하였다. BasicErrorController에서 벗어나보자.. -> 요청 header의 accept가 applicatio..

이전 포스팅에서 확인했을 때, 예외가 발생했을 때, BasicErrorController 에서 제공해주는 Json 응답 기능은 편리하다. 하지만.. 아래는 현재까지 문제점이다. 1. 일반 예외의 경우 Http status 조절을 못한다. (sendError의 경우 조절 가능) 2. 개발자가 정한 사양대로의 응답 데이터로 못 내려준다. (BasicErrorController가 기본으로 제공하는 응답 json 데이터가 내려감) (물론 1, 2번 모두 BasicErrorController를 확장하면 가능하다..) HandlerExceptionResolver를 이용하여 위 문제를 해결해보자 일반 예외가 발생하였을 땐.. 기본적으로 WAS에서는 500 Status 값으로 처리된다. 이를 400으로 바꿔 보겠다....

이번엔 API 응답의 경우 예외처리 방법에 대해 알아보자.. (html 응답의 경우 특정 경로에 400대, 500대 오류페이지만 만들어주면 됐었다..) 예외가 발생 했을 때.. HTTP API 응답 보통 요청을 보낼때 HTTP header에 accept 값으로 application/json 으로 들어온다. 서블릿을 이용할 경우.. accept 가 다르게 들어오는것을 활용하여.. 전용 컨트롤러를 만들어준다. 예외처리 2번 포스팅의 ErrorPage 객체를 등록해주는 WebServerFactoryCustomizer 구현체의 연장선이다. produces 요소를 활용하여 요청 Http header의 accept가 application/json 인 경우에 적용되는 컨트롤러로 만들어준다. jackson 라이브러리는..