Spring Data JPA 조회 방식 선택¶
두 축은 독립: ①쿼리 작성 방식(Derived/JPQL/Native/QueryDSL) × ②결과 매핑(Entity/Interface Projection/Class Projection).
1. 쿼리 작성 방식¶
| 방식 | 장점 | 단점 | 적합 |
|---|---|---|---|
| Derived Query | 코드 최소, 컴파일 타임 필드 검증 | JOIN/집계/동적 불가 | 단순 단건/목록, 조건 1~2개 |
JPQL (@Query) |
JOIN/집계/서브쿼리, 엔티티 기반 | 동적 조건 약함, MySQL 함수 X | 고정 조건 JOIN+집계 |
| Native Query | MySQL 전용 함수·힌트 완전 지원 | DB 종속, 컬럼명 직접 관리 | MySQL 함수 필수 / 성능 직접 제어 |
| QueryDSL | 타입 세이프 동적 조건·페이징·집계 | 초기 설정(APT/Q클래스) | 동적 필터+페이징, 복잡 검색 |
2. 결과 매핑¶
- Entity — 영속성 컨텍스트 관리(변경 감지/lazy). 쓰기에 적합. 조회 전용으로 쓰면 오버헤드
- Interface Projection — 런타임 프록시. Closed(필요 컬럼만 SELECT) / Open(
@ValueSpEL, 전체 fetch) / Nested(N+1 주의) - Class Projection (
record권장) — 진짜 객체·불변·테스트 용이. Nested 불가
3. DiEdu 선택 플로우¶
동적 조건 필요?
├ YES → QueryDSL + Class Projection (Projections.constructor)
└ NO
├ MySQL 전용 함수? → Native Query + Interface Projection
├ JOIN/집계? → JPQL(@Query) + Class Projection (record)
└ 단순 조회
├ Nested 연관 필요? → Derived Query + Interface Projection
└ 그 외 → Derived Query + Class Projection(record)/Entity
4. 영속 엔티티 조립 / 어댑터¶
저장 시 연관 엔티티는 findById로 영속 상태로 조회 후 조립할 것(비영속 엔티티 문제 방지). 변환 책임은 어댑터. 상세는 teams/engineering/guides/backend-architecture §3.
5. 관련¶
- teams/engineering/guides/soft-delete — 벌크 UPDATE는
@SQLDelete대신@Modifying @Query(1+N 회피) - Spring Data JPA Projections 공식