프로젝션
: select 대상 지정
프로젝션 대상 개수
1개 : 타입 명확하게 지정 가능
2개 이상 : Tuple 또는 DTO로 조회
- 튜플 패키지
package com.querydsl.core
👉 결국 Querydsl에 종속적인 기술이므로 Repository를 벗어나는 것은 좋지 않다
👉 외부로는 DTO로 변환하여 사용
DTO 조회 방법
순수 JPA
em.createQuery(
"select new study.querydsl.dto.MemberDto(m.username, m.age) from Member m",
MemberDto.class)- new 명령어 사용
- DTO의 package이름을 적어야 하므로 지저분
- 생성자 방식만 지원
Querydsl
1) 프로퍼티 접근
Projections.bean
.select(Projections.bean(MemberDto.class, member.username, member.age))- setter를 사용하여 값을 넣음
- setter가 없는 경우 객체는 생성되나 값이 없음
- DTO를 만들어야 하므로 기본 생성자 필요
- DTO와 Entity 필드명 매칭 중요, 이름이 같아야 함
2) 필드 직접 접근
Projections.fields
.select(Projections.fields(MemberDto.class, member.username, member.age))- getter, setter 필요 없음
- DTO와 Entity 필드명 매칭 중요, 이름이 같아야 함
3) 생성자 사용
Projections.constructor
.select(Projections.constructor(MemberDto.class, member.username, member.age))- Entity 와 DTO 의 필드 타입이 같고, 같은 타입의 생성자 필요
- 필드명은 달라도 됨
4) 생성자 사용 2 : @QueryProjection
.select(new QMemberDto(member.username, member.age))- DTO의 생성자에 @QueryProjection 애노테이션을 사용하면 Q파일로 생성됨
- DTO의 생성자를 사용하므로 타입이 맞는 장점
- 생성자 타입이 맞지 않으면(새로운 필드가 추가되면) 컴파일 오류
but
- Q파일 생성하므로 DTO 가 Querydsl에 의존성을 가짐
- 순수하지 않은 DTO가 여러 레이어에 걸쳐 돌아다니게 됨
실용적 관점 vs 아키텍처 관점
🔎 constructor 와 @QueryProjection 의 차이
| constructor | @QueryProjection |
|---|---|
| 런타임 오류 (실행해야 알 수 있음) | 컴파일 오류 (실행 전 발견) |
