JPA -> JDBC 변환 계획

[InHyeok-J]

기존 JPA 구조

• data JPA / QueryDSL 사용
• domain 모듈 안에 interface JPA를 사용.
  • Application / domain이 JPA에 의존하고 있음.

왜 바꿔야 하는지

• Lazy Loading 사용 시 의도하지 않은 쿼리가 날아갈 수 있음.
• JPA가 만들어주는 쿼리를 명확하게 알지 못하고 사용하는 경우 문제가 발생할 수 있다.
• 기존에는 어떤 쿼리가 어떻게 어떤 순간에 실행되는지 직접적으로 파악할 수 없음.
• 백엔드 취준생 입장에서 쿼리에 대한 공부를 해야 하는데 공부 기회가 없어진다.
  • data JPA와 QueryDSL이 자동으로 만들어주기 때문에 쿼리에 대한 공부가 강제가 아니게 된다.

JDBC로 변환 시 예상되는 문제점

1. 동적 쿼리 최적화 불가능

   • 코드레벨로 구현이 필요하다 (if else)

2. Lazy Loading이 필요한 상황에서 한번에 (하나의 메소드) 쿼리를 다 날려서 데이터를 가져와야 한다.

   1. 최적화를 위해서 다양한 DAO 메소드가 필요하게 됨.
   2. 필요한 경우 메소드로 분리하고
   3. 분리할 때 쓰는 메소드 네이밍 (스펙)

3. 기존 JPA에서 해주는 AutoIncrement와 TSID 동작을 직접 구현해야 한다.

   1. 라이브러리가 있음.
   2. TSID Creator 라이브러리 링크

변환 작업

변환 수행 전 제안 사항

• 기존 domain 모듈이 JPA를 알고 사용하고 있었는데 이 부분을 격리해보자.

  • infra 모듈에 구현체 위치.
  • 도메인 모듈에 의존하고 있는 JPA, QueryDSL 의존성들은 모두 infra로 이동

• domain 모듈은 POJO 객체 유지

• domain 모듈의 repository 코드는 java 인터페이스로 유지하고 DIP 적용

• Infra 모듈에 구현체 위치 / 도메인 객체로 변환해주는 mapper 구성

변환 수행 단계

1. 인프라에도 JPA&QueryDSL 의존성 추가 / 다음 구현, 기존 구현에 DIP만 적용

   • 앞으로의 작업에 DIP가 적용된 서비스 코드 사용
   • 기존에 코드도 수정 DIP 통해서 수정
     • 기존 코드는 JPA 그대로 쓰고
     • 새로운 코드는 JDBC Template
   • 모든 구현체 Infra 모듈로 이전

2. 테스트 코드 작성

3. 각자 코딩한 부분에 맞게 하나씩 구현체 수정

4. domain에 JPA 의존 삭제 (완료)

메소드 네이밍 컨벤션

기본

기능 / 접두사	리턴 타입
생성 - save	Entity
수정 - update	void
삭제 - delete	void
조회 - find	Optional
조회 - findAll	List

UseCase.행위 → Service.getById / Service.findById Optional→ Repository.find

특정 연관관계가 같이 들어온 경우

기능 / 접두사	리턴 타입
A.findWithBAndC	A와 B, C를 조인해서 가져오겠다.

[InHyeok-J]

해당 과정은 JPA의 쿼리 분석으로 대신하기로 결정됨