[스프링 데이터 JPA] 7. 나머지 기능들

 

오늘 강의들은 내용은 실무에서는 엄~~~청 자주 사용하지는 않지만 

그래도 있는 기능들이고, 잘 사용하면 나름 유용하게 쓸 수 도 있다고 해서 소개하는 섹션이라고 한다. 

 

1️⃣ Specifications (명세)

: 책 도메인 주도 설계 (Domain Driven Design)는 SPECIFICATION(명세) 라는 개념을 소개하는데 

스프링 데이터 JPA 는 JPA Criteria를 활용해서 이 개념을 사용할 수 있도록 지원한다. 

(일단 JPA Criteria를 활용해서 지원한다는 것 자체부터가 실무에서 사용하기엔 힘들다는 얘기다.. ) 

 

술어 Predicate 

- 참 또는 거짓으로 평가 

- AND OR 같은 연산자로 조합해서 다양한 검색조건을 쉽게 생성(컴포지트 패턴) 

- 예) 검색 조건 하나하나 

- 스프링 데이터 JPA는 org.springframework.data.jpa.domain.Specification 클래스로 정의 

 

❗ 컴포지트 패턴

객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴

 

 

명세 기능 사용 방법

: JpaSpecificationExecutor 인터페이스 상속 

 

MemberRepository

 

JpaSpecificationExecutor

-> Specification을 파라미터로 받아서 검색 조건으로 사용 

 

 

MemberRepositoryTest

😎 Specification 을 구현하면 명세들을 조립할 수 있음. 

-> where(), and(), or(), not() 제공 

 

Specification 인터페이스를 구현한 것을 and로 연결하고 싶으면 연결할 수 있고, 

JpaSpecificationExecutor 를 상속했기 때문에 그냥 memberRepository.findAll()에서 Specification 구현한 것을 그냥 파라미터로 넘기면 알아서 sql을 만들어준다. 

 

-> findAll을 보면 회원 이름 명세 username와 팀 이름 명세 teamName 을 and 로 조합해서 검색 조건으로 사용

 

 

MemberSpec

-> 명세를 정의하려면 Specification 인터페이스를 구현해야한다. 

명세를 정의할 때는 toPredicate(...) 메서드만 구현하면 되는데 JPA Crieria의 Root, CriteriaQuery, CriteriaBuilder 클래스를 파라미터 제공 

 

⭐참고

: 실무에서는 JPA Criteria 를 거의 안쓴다..!!! 이것도 참고로만 보고 QueryDSL을 사용하는 것을 권장한다. 

강의 내내 강사님이 사용하면 엄청 후회할 거라고 그냥 사용하지 않는것을 추천한다고 몇번이나 강조했다. ㅋㅋㅋㅋㅋ

 

 

 

2️⃣ Query By Example

https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#query-by-example

Spring Data JPA - Reference Documentation

 

MemberRepositoryTest

Probe: 필드에 데이터가 있는 실제 도메인 객체 

-> Member 객체를 생성한 다음에 Team 객체도 생성하고 연관관계로 세팅해줌 -> 내부조인으로 teamA 가능 

 

ExampleMatcher : 특정 필드를 일치시키는 상세한 정보 제공, 재사용 가능 

-> ExampleMatcher를 생성해서 age 프로퍼티는 무시하도록 설정했다. 이거 있으면 select 할 때 age 도 포함해서 쿼리함. 

-> ExampleMatcher 제거했을 때 

age는 int형으로 기본 타입이기 때문에 기본 값이 0이 있어서 쿼리할 때 이것도 포함해서 조회하게 됨..!

 

 

Example : Probe와 ExampleMatcher 로 구성, 쿼리를 생성하는데 사용 

-> Example에 Probe인 Member와 ExampleMatcher 인 example을 Example.of 파라미터로 제공해주고, 이를 memberRepository.findAll에 넘겨주면 검색 조건을 포함한 sql을 생성한다. 

 

장점

- 동적 쿼리를 편리하게 처리 
- 도메인 객체를 그대로 사용 
- 데이터 저장소를 RDB에서 NOSQL로 변경해도 코드 변경이 없게 추상화 되어 있음
- 스프링 데이터 JPA JpaRepository 인터페이스에 이미 포함 

 

단점 

- 조인은 가능하지만 내부 조인(INNER JOIN)만 가능함, 외부 조인(LEFT JOIN) 안됨
- 중첩 제약 조건 안됨 
ex) firstname = ?0 or (firstname = ?1 and lastname = ?2) 
- 매칭 조건이 매우 단순함 (정확한 매칭 (=)만 지원) 

 

❗ 정리

실무에서 사용하기에는 매칭 조건이 너무 단순하고, LEFT 조인이 안됨

-> inner join만 제공하기 때문에 outer join이 들어가려고 하면 결국 이 코드들을 모두 제거하고 다시 해야 하기 때문에...  

실무에서는 QueryDSL 을 사용합시다..!!!!

 

 

 

3️⃣ Projections 

https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#projections

Spring Data JPA - Reference Documentation

 

: 엔티티 대신에 DTO를 편리하게 조회할 때 사용 

(전체 엔티티대신에 회원 이름만 조회하고 싶을 때..?) 

 

UsernameOnly

-> 조회할 엔티티의 필드를 getter 형식으로 지정하면 해당 필드만 선택해서 조회 (Projection)

 

MemberRepository

-> 메서드 이름은 자유이고, 반환 타입으로 인지한다. 

 

MemberRepositoryTest

-> SQL에서도 select 절에서 username만 조회(Projection) 하는 것을 확인할 수 있다. 

 

 

- 인터페이스 기반 Closed Projections

: 프로퍼티 형식(getter)의 인터페이스를 제공하면, 구현체는 스프링 데이터 JPA가 제공한다. 

 

- 인터페이스 기반 Open Projections

: 스프링의 SpEL 문법을 지원한다. 

근데 SpEL 문법을 사용하면 DB에서 엔티티 필드를 다 조회해온 다음에 계산하기 때문에 JPQL SELECT 절 최적화가 되지 않는다..!! 

-> 인터페이스 기반 Open Projections 를 사용하면 SQL SELECT절이 최적화 되지 않는 것을 확인할 수 있다. 

 

 

- 클래스 기반 Projection

UsernameOnlyDto

-> 다음과 같이 UsernameOnly 인터페이스가 아닌 구체적인 DTO 형식도 가능하다.

생성자의 파라미터 이름으로 매칭 

 

MemberRepository

 

MemberRepositoryTest

 

- 동적 Projections

MemberRepository

 

MemberRepositoryTest

 GenericType으로 주면 동적으로 프로젝션 데이터 변경 가능하다. 

 

 

- 중첩 구조 처리

NestedClosedProjection

 

MemberRepository

 

MemberRepositoryTest

-> 아까 동적 Projections에 중첩 구조 클래스를 담고 리턴해주면 된다. 

 

 

❗ 주의

프로젝션 대상이 root 엔티티이면, JPQL SELECT절 최적화 가능 

프로젝션 대상이 ROOT가 아니면 

- LEFT OUTER JOIN 처리 

- 모든 필드를 SELECT 해서 엔티티로 조회한 다음에 계산 

 

⭐ 정리

- 프로젝션 대상이 root 엔티티면 유용하다. 

그런데 프로젝션 대상이 root 엔티티를 넘어가면 JPQL SELECT 최적화가 안된다..!

->위에 쿼리를 보면 Member에서는 username만 조회하면서 최적화가 됐지만, 

team은 root 엔티티가 아니기 때문에 select 에서 최적화되지 않은 것을 확인할 수 있다. 

- 실무의 복잡한 쿼리를 해결하기에는 한계가 있다. 

- 실무에서는 단순할 때만 사용하고, 복잡해지면 QueryDsl을 사용하자..!!!

 

 

4️⃣ 네이티브 쿼리 

이번 강의를 들을 때는 거의 사용하라고 권장하는 건 없었던것 같다. 

들으면서도 ?-? 이러면서 들은듯..ㅋㅋㅋ

 

아무튼 네이티브 쿼리도 가급적 사용하지 않는게 좋고, 정말 어쩔~~수 없을 때 사용하라고 한다.

소개도 최근에 나온 궁극의 방법인 스프링 데이터 Projections을 활용해서 할 수 있는 방법이 있어서 한다고 한다. 

 

- 스프링 데이터 JPA 기반 네이티브 쿼리 

페이징 지원 

반환 타입 : Object[], Tuple, DTO(스프링 데이터 인터페이스 Projections 지원) 

제약

- Sort 파라미터를 통한 정렬이 정상 동작하지 않을 수 있다.  (됐다 안됐다 하기 때문에 믿지 말고 직접 처리하라고 함) 
- JPQL 처럼 애플리케이션 로딩 시점에 문법 확인 불가 
- 동적 쿼리 불가 

 

- JPA 네이티브 SQL 지원

 

- Projections 활용

-> 스프링 데이터 JPA 네이티브 쿼리 + 인터페이스 기반 Projections 활용 

 

MemberProjection 

 

 

❗ 강사님도 그냥 네이티브 쿼리를 사용하기보다는 JdbcTemplate를 사용하기도 한다고 한다. 

네이티브 쿼리는 가급적 사용하지 말자~~