[Spring 실습] 점심 추천 & 투표 서비스 만들기 v1

☠️ 트러블 슈팅

발생한 Issue 

• 1. Mybatis ↔︎ JPA 로의 전환 과정에 대한 개념 이해가 필요했음
  • 왜 이렇게 수정해야하며 어떤 기능을 대체하는 것인가?
• 2. Mapper → Repository 로의 전환 과정에서 놓치지 말아야 할 부분이 무엇인지 확실하지 못했음
  • 기존에 사용되었던 RoundTodayRounds() 와 getRound의 개념을 이해해야 했음
  • 왜 메서드네이밍으로 구현하지 못하고 JPQL로 처리해야하는지에 대한 이해가 부족했음 

해결방법 / 찾아본 내용

• 1. MyBatis ↔︎ JPA의 차이 정리
  • MyBatis는 SQL이 중심, JPA는 엔티티 가 중심 (생산성 및 일관성을 향상시키는 장점을 가지게 됨)
    → XML 매퍼/Mapper 인터페이스를 @Entity + Repository로 바꾸는 과정이 필요
  • DB 생성은 MyBatis에서 JPA로 수정하기 이전에 생성했으므로 ddl-auto=validate로 검증만 우선 진행이 필요
  •  
• 2. MyBatis → Jpa로 사용할 수 있는 데이터 접근 방식은 아래와 같음
  • 메서드 이름 기반 쿼리
  • JPQL(Java Persisence Query Language)
  • Native SQL
  • Criteria API
  • QueryDSL

각 접근방식을 표로 정리하자면

방식	작성 난이도	유지보수성	성능	동적 쿼리	특징
메서드 네이밍	★☆☆	★★★	✅	❌	단순 조건에 최적
JPQL	★★☆	★★☆	✅	❌	SQL 없이도 엔티티 중심으로 join 가능
Native SQL	★★☆	★☆☆	✅	⭕	DB 의존적, 복잡 쿼리 대응
Criteria API	★★★	★★☆	✅	⭕	코드 기반 JPQL 생성 (복잡함)
QueryDSL	★★☆	★★★	✅	⭕⭕	실무 표준, 타입 안전, 유지보수 좋음

위와 같이 정리할 수 있었고 

 

이번 과정에서 선택해야 하는 기준은 

• 간단한 CRUD / 조건 1~2개 → 메서드 이름 기반
• 조인, 필터, DTO 반환 등 복잡도가 어느정도 있을 때 → JPQL (@Query)
• 복잡한 검색, 조건이 많거나 필터링 다양한 경우 → QueryDSL
• DB 특화 함수/쿼리 필요한 경우 → Native SQL 

로 정리할 수 있었고 JPQL을 사용하여 전환하는 과정이 필요함을 알게 되었다 .