1장. JPA 소개

1장은 간단히 JPA에 대한 소개이다.

 

SQL을 직접 다룰 때 여러 문제들이 있지만..

그렇다고 도메인 모델을 객체로 모델링하자니 두 패러다임 간의 불일치로 생기는 문제를 알려주고 있다.

위 두 문제들을 나이스하게 해결해주는 방법으로 JPA를 소개하고 있고

Q&A 파트에서 실 사용자가 궁금해할만한 내용들을 이야기해주고 있다.

 

'왜' 쓰는지 알아야 열심히, 잘 쓸 수 있기 때문에 흥미롭게 읽었다.

JPA의 핵심 개념들을 이해해야 함
핵심 개념인 영속성 컨텍스트에 대한 이해가 부족하면 SQL을 직접 사용하는 것보다 못한 상황이 발생할 수 있음

(특히나 매우 찔렸던 부분)

---

1.1 SQL을 직접 다룰 때 발생하는 문제점

• SQL을 사용해서 객체를 다루려면 번거롭다
• 진정한 의미의 계층 분할이 어렵다
  • 물리적으로는 SQL과 JDBC API를 데이터 접근 계층에 숨겼을지라도
  • 논리적으로 엔티티와 아주 강한 의존관계를 가지고 있다
  • 결국 DAO를 열어서 어떤 SQL이 실행되는지 확인해야 한다.

1.2 패러다임의 불일치

도메인 모델도 객체로 모델링하면 객체지향 언어가 가진 장점들을 활용할 수 있지만,

도메인 모델을 저장할 때 여러 문제가 발생함

• 객체
  • 속성 : 상태 (field)
  • 기능 (method)
• 관계형 데이터베이스
  • 데이터 중심으로 구조화 됨
  • 집합적 사고 요구
  • 객체지향에서 이야기하는 추상화, 상속, 다형성 개념이 없음
• 객체 to 관계형 데이터베이스
  • 객체의 기능은 class에 저장되어 있으므로 속성만 저장하면 됨.
  • 모든 속성 값을 꺼내서 DB에 저장하면 된다.
  • 하지만 상속이나, 참조가 있다면?
  • 자바는 이런 문제를 고려해 객체를 저장하는 직렬화 기능과 저장된 파일을 객체로 복구하는 역 직렬화 기능을 지원한다.
  • 하지만 이 방법은 직렬화된 객체를 검색하기 어렵다는 문제가 있으므로 현실성이 없다.
    • ❓ SQL처럼 KEY 값으로 조회하기 힘들다는 말인가? → 데이터가 하나로 뭉쳐서 직렬화되므로 검색하기 어렵다.

→ 객체 구조를 테이블 구조에 저장하는 데는 한계가 있다.

(상세 설명은 도식과 코드가 있는 책을 보는 것이 더 이해가 빠르다.)

1.2.1 상속

• 객체는 상속을 지원하지만
• 테이블은 상속이 없다.
  • 그나마 슈퍼타입 서브타입 관계를 사용하면 비슷하게 설계 가능
• 실 구현체가 부모를 상속한만큼 쿼리를 추가 작성 필요

→ JPA 사용 시 자동 처리해줌

1.2.2 연관관계

• 객체는 참조를 사용해서 연관관계를 맺고 참조에 접근해서 연관된 다른 객체를 조회한다
  • 객체는 참조가 있는 방향으로만 조회할 수 있다
• 테이블은 외래키를 사용해서 연관관계를 맺고 조인을 사용해서 조회한다
  • 양방향 참조 가능

→ JPA 사용 시 자동 처리해줌

1.2.3 객체 그래프 탐색

• 객체가 참조하고 참조하고… 또 그 객체가 참조하는 다른…. 이런 그래프를 자유롭게 탐색 가능해야한다.
• SQL을 직접 다루면 최초 실행되는 SQL에 따라서 탐색가능한 영역이 정해진다.
  • 그렇다고 연관된 모든 테이블을 JOIN해서 메모리에 올려두는 것은 현실성이 없다.

→ JPA 사용 시 사용하는 시점에 필요한 데이터를 조회하는 ‘지연 로딩’ 기능이 있음 (설정 가능)

1.2.4 비교

• DB는 기본 키 값으로 UNIQUE 체크함
• 객체
  • identity (동일성) 비교
    • == 비교
    • 객체 인스턴스 주소 값 비교
  • equality (동등성) 비교
    • equals() 메소드 비교
    • 객체 내부의 값 비교

→ JPA 사용 시 같은 트랜잭션일 때 같은 객체가 조회되는 것을 보장함

1.3 JPA란 무엇인가?

• JPA(Java Persistence Api) : java 진영의 ORM 기술 표준
• ORM(Object Relational Mapping) : 객체와 관계형 데이터베이스를 매핑한다
• ORM 프레임워크
  • 객체와 테이블을 매핑해서 패러다임의 불일치 문제를 개발자 대신 해결
  • 객체 측면에서 정교한 모델링이 가능
  • 관계형 데이터베이스는 데이터베이스에 맞도록 모델링 가능
  • 객체 - 데이터베이스 를 어떻게 매핑해야하는지 개발자가 알려줘야 함

1.3.1 JPA 소개

• Hibernate
  • java 진영의 오픈소스 ORM 프레임워크
  • hibernate를 기반으로 JPA가 만들어짐
• JPA는 ORM interface이기 때문에 구현체가 필요
  • hibernate 가 구현체 (다른 구현체들도 있으나 hibernate가 가장 대중적)

1.3.2 왜 JPA를 사용해야 하는가?

• 생산성 : 반복적인 CRUD 코드를 JPA가 대신 해줌
• 유지보수 : field 추가/삭제에 따른 작업을 JPA가 대신 해줌
• 패러다임의 불일치 해결 : 상속, 연관관계, 객체 그래프 탐색, 비교하기 등 패러다임 불일치 문제 해결
• 성능
  • JPA는 어플리케이션과 데이터베이스 사이에서 동작함
  • 어플리케이션과 데이터베이스 사이에 계층이 하나 더 있으면 최적화 관점에서 시도해볼 수 있는 것들이 있음
    • ex) 같은 트랜젝션에서 같은 회원 2번 조회
      • JDBC API로 작성했다면 데이터베이스와 2번 통신했을 것
      • JPA를 사용하면 데이터베이스와 1번 통신하고 두번째는 이미 조회된 회원 객체를 재사용함
    • String memberId = "memberId"; Member member1 = jpa.find(memberId); Member member2 = jpa.find(memberId);
    • ex) 하이버네이트의 SQL 힌트 기능
• 데이터 접근 추상화와 벤더 독립성
  • 관계형 데이터베이스는 같은 기능도 벤더마다 사용법이 다를 수 있음
    • ex) 페이징 처리
  • SQL문으로 작성한 데이터베이스 기술에 종속되고 다른 데이터베이스로 변경하기가 어려움
  • JPA 사용 시 추상화된 데이터 접근 계층을 제공해 변경이 자유로움
• 표준
  • 표준을 사용하면 다른 구현 기술로 손쉽게 변경할 수 있다.

Q&A ORM에 대한 궁금증과 오해

• ORM 프레임워크를 사용하면 SQL과 DB는 잘 몰라도 되나?
  • ORM 프레임워크가 객체지향 개발을 도와주긴 하지만 데이터는 결국 관계형 DB에 저장된다.
  • 테이블 설계는 여전히 중요하고 SQL도 잘 알아야 한다.
  • ORM의 가장 중요한 일은 객체-테이블 매핑인데 양쪽 다 이해해야 한다
• 성능이 느리진 않나?
  • JPA는 다양한 성능 최적화 기능을 제공한다
  • 잘 이해하고 사용하면 SQL 직접 사용보다 더 좋은 성능을 낼 수도 있음
  • 네이티브 SQL을 사용해서 직접 호출도 가능
  • 잘 이해하지 못하고 사용하면 N+1 같은 문제가 발생할 수 있으니 유의
    • 1번 호출(n개 row)에 연관테이블 n번이 호출되는 이슈
• 통계 쿼리처럼 매우 복잡한 SQL은 어떻게 하나?
  • JPA는 복잡한 쿼리보다는 실시간 처리용 쿼리에 더 최적화되어있다.
  • 정말 복잡한 쿼리는 SQL 직접 작성이 더 쉬울수도 있다.
  • 네이티브 SQL을 사용하거나 Mybatis, jdbcTemplate 같은 SQL 매퍼를 혼용하는 것을 추천fmf
• Mybatis와의 차이?
  • Mybatis, jdbcTemplate : SQL 매퍼 → 객체와 SQL 매핑
    • SQL과 매핑할 객체 지정 필요
    • JDBC API 사용과 객체 매핑을 SQL 매퍼가 대신 처리
    • 하지만 SQL은 개발자가 작성해야 함
  • ORM은 SQL도 프레임워크가 대신해준다!
    • 객체와 테이블 매핑 필요
• 학습 곡선이 높다던데?
  • 객체와 DB를 어떻게 매핑하는지 학습하고
  • JPA의 핵심 개념들을 이해해야 함
    • 핵심 개념인 영속성 컨텍스트에 대한 이해가 부족하면 SQL을 직접 사용하는 것보다 못한 상황이 발생할 수 있음
  • JPA가 어려운 이유는 ORM이 객체지향-관계형 DB라는 두 개념 위에 있기 떄문
    • 두 개념의 기초가 부족하면 어려울 수 있음