개발의 시작 개발의 시작

우선 간단하게 Mybatis가 뭔지 알아보고 설정하는 법을 보여드리겠습니다. 마이바티스(Mybatis)는 JdbcTemplate보다 더 많은 기능, 편리성을 가지고 있고, 개발자가 지정한 SQL, 저장프로시저 그리고 몇 가지 고급 매핑을 지원하는 퍼시스턴스 프레임워크입니다. 마이바티스는 JDBC로 처리하는 상당 부분의 코드와 파라미터 설정 및 결과 매핑을 대신해준다. 참고 : https://mybatis.org/mybatis-3/ko/index.html build.gradle implementation 'org.mybatis.spring.boot:mybatis-spring-boot-starter:2.2.0' (스프링이 공식적으로 지원하는 라이브러리가 아닌 경우는 버전 정보를 적어주셔야 합니다.) 우선, ..

Swagger 설정에 앞서 Swagger가 뭔지 알아보겠습니다. Swagger란 OAS(Open Api Specification)을 위한 오픈소스 프레임워크이다. - API 개발 과정에서 변경이 있으면 그에 따른 명세(Spec)도 변경이 있을 것이다. 이러한 작업은 번거롭고 시간 또한 오래 걸린다. 이 같은 문제를 해결하기 위한 것이 바로 Swagger라는 프로젝트이다. (API가 수정돼도 자동으로 문서가 갱신된다.) 더보기 What is the OpenAPI Specification? The OpenAPI Specification, formerly known as the Swagger Specification, is the world’s standard for defining RESTful interf..

우선 간단하게 Querydsl이 뭔지 알아보고 설정하는 법을 보여드리겠습니다. Querydsl 이란 이전에 Spring boot + Spring data jpa 기술들의 조합으로 해결하지 못하는 한계점을 해결하기 위해 나온 프레임워크입니다. (JPQL 빌더 역할을 해주는 오픈소스 프로젝트) 한계점이란, 실무에서는 당연히 복잡한 쿼리를 다루게 될 수도 있고, 조건에 따라 복잡한 동적 쿼리들을 생성할 일이 많을 수 있습니다. 이런 문제들을 해결할수 있는 기술이 바로 Querydsl입니다. 또한 Querydsl의 큰 장점은 쿼리를 "자바 코드"로 작성하여 문법 오류를 컴파일 시점에 확인할 수 있습니다. 이러한 Querydsl을 사용을 사용하려면 다음과 같은 설정 작업을 하셔야 합니다. build.gradle ..

EntityGraph는 페치 조인(FETCH JOIN)의 간편 버전이라고 생각하면 됩니다. EntityGraph의 4가지 사용법을 알아보겠습니다. [ 이전 글(페치조인 설명)을 꼭 참고해주세요. ] 저번 시간에 이어 먼저 MemberRepository를 살펴보겠습니다. 첫 번째 방법 27라인을 보시면 엔티티 그래프가 추가 되었습니다. 이전과는 달리 [ @Query("...") 페치 조인을 위한 JPQL쿼리를 ] 짜지 않고 @EntityGraph를 이용하여 페치 조인을 사용할 수 있습니다. 바로 테스트해보겠습니다. 결과 이전 페치조인과 동일한 결과를 얻을 수 있습니다. 두 번째 방법 31라인을 보시면 엔티티 그래프 사용 두 번째가 추가되었습니다. 이번에는 JPQL과 엔티티 그래프를 같이 사용하는 방법입니다..

페치(fetch)조인은 SQL에서 사용하는 조인의 종류는 아니고 JPQL에서 성능 최적화를 위해 제공하는 기능입니다. 이것은 연관된 엔티티나 컬렉션을 한 번에 같이 조회하는 기능인데 join fetch 명령어로 사용할 수 있습니다. 페치 조인을 사용해서 회원(Member) 엔티티를 조회하면서 연관된 팀(Team) 엔티티도 함께 조회하는 JPQL을 실행해보겠습니다. 이해를 돕기 위해 회원, 팀 엔티티부터 순서대로 살펴보겠습니다. 23~25 라인을 보시면 Team엔티티와 N:1 관계, 지연 로딩으로 설정되어 있는걸을 확인하실 수 있습니다. (FetchType.LAZY) 23~24 라인을 보시면 Member엔티티와 양방향 매핑으로 되어있다는 것을 확인하실수 있습니다. 다음으로는 MemberRepository를..

스프링 부트에서 API예외처리를 글로벌하게 처리하는 방법을 알아보겠습니다. 이전 글 에서는 해당 컨트롤러에서만 예외 처리 적용이 되게 설정을 하였다면, 이번 글에선 글로벌하게 처리하는 법을 알아보겠습니다. [이전 스프링 부트에서 API예외 처리하는 법 글을 보지 않으셨던 분은 꼭 보고 와 주세요!] 우선 이전 코드를 보겠습니다. 보시다시피 정상 코드와 예외처리 코드가 하나의 컨트롤러에 섞여있습니다. 정상 코드와 예외 처리 코드를 분리하고 싶다면 @ControllerAdvice 또는 @RestControllerAdvice를 사용하면 둘을 분리할 수 있습니다. 이 둘의 차이점을 보기 위해 RestControllerAdvice 내부 코드를 캡처 @ControllerAdvice는 대상으로 지정한 여러 컨트롤러에..

스프링 부트에서 API예외 처리하는 3가지 방법을 사용해보겠습니다. 먼저 스프링에서 exception을 처리해주는 HandlerExceptionResolver을 알아보겠습니다. 일반적으로 오류 view에 대한 핸들러 매핑 또는 실행 중에 발생한 예외를 해결할 수 있는 개체에 의해 구현되는 인터페이스입니다. (예외가 던져졌을 때 어떤 핸들러를 실행할 것인지에 대한 정보를 제공) 스프링 부트가 기본으로 제공하는 3가지 ExceptionResolver을 알아보겠습니다. (우선순위 순을 정렬) ExceptionHandlerExceptionResolver ResponseStatusExceptionResolver DefaultHandlerExceptionResolver 우선 순위 반대로 하나씩 살펴보겠습니다. 1...

스프링 인터셉터란 사전적 의미로 가로채다는 의미가 있습니다. 이걸 스프링에 적목 시키면 인터셉터는 Controller에 들어오는 요청(HttpRequest), 응답(HttpResponse)를 가로채는 역할을 하는 객체입니다. 인터셉터는 이전 시간에 본 서블릿 필터와 같이 웹과 관련된 공통 관심 사항을 효과적으로 해결할 수 있는 기술입니다. 차이점 이라하면 서블릿 필터는 서블릿이 제공하는 기술이고, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이고, 둘 다 웹과 관련된 공통 관심 사항을 처리하지만, 적용되는 순서와 범위, 그리고 사용법이 차이점이 있습니다. 인터셉터는 어떻게 적용되고, 사용되는지 알아보겠습니다. 스프링 인터셉터 흐름 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 ..