[스프링 DB 2편] #5. 데이터 접근 기술 - JPA(1)

[newh08]

JPA 시작

스프링과 JPA는 자바 엔터프라이즈(기업) 시장의 주력 기술이다.
스프링이 DI 컨테이너를 포함한 애플리케이션 전반의 다양한 기능을 제공한다면, JPA는 ORM 데이터 접근 기술을 제 공한다.

사용 조합 구글 트랜드 비교

• 글로벌에서는 스프링+JPA 조합을 80%이상 사용한다.
• 국내에서도 스프링 + JPA 조합을 50%정도 사용하고, 2015년 부터 점점 그 추세가 증가하고 있다.

JPA는 스프링 만큼이나 방대하고, 학습해야할 분량도 많다. 하지만 한번 배워두면 데이터 접근 기술에서 매우 큰 생산 성 향상을 얻을 수 있다.
대표적으로 JdbcTemplate이나 MyBatis 같은 SQL 매퍼 기술은 SQL을 개발자가 직접 작성 해야 하지만, JPA를 사용하면 SQL도 JPA가 대신 작성하고 처리해준다. (기본적인 등록, 수정, 삭제, 조회 다 제공)

실무에서는 JPA를 더욱 편리하게 사용하기 위해 스프링 데이터 JPA와 Querydsl이라는 기술을 함께 사용한다. 중요한 것은 JPA이다. 스프링 데이터 JPA, Querydsl은 JPA를 편리하게 사용하도록 도와주는 도구라 생각하면 된다.
이 강의에선 JPA와 스프링 데이터 JPA, 그리고 Querydsl로 이어지는 전체 그림을 볼 것 이다. 그리고 이 기술들을 우리 애플리케이션에 적용하면서 자연스럽게 왜 사용해야 하는지, 그리고 어떤 장점이 있는지 이해할 수 있게 된다.

각각의 기술들은 별도의 강의로 다룰 정도로 내용이 방대하다. 여기서는 해당 기술들의 기본 기능과, 왜 사용해야 하는지 각각의 장단점을 알아본다.

ORM 개념1 - SQL 중심적인 개발의 문제점

애플리케이션은 객체
데이터는 관계형 DB 에 저장.
즉 관계형 DB 에 객체를 저장.

만약 객체에 필드가 추가되면 모든 SQL 에 쿼리를 수정해야함.

또 update 쿼리에서만 추가된 필드를 누락해버리면 큰 문제가 발생함.
그래서 SQL 의존적인 개발을 피하기 어려움.

그리고 객체와 관계형데이터베이스는 페러다임이 다름.

객체를 SQL로 변환해서 저장함. 이 변환을 개발자가 진행함 (SQL 맵퍼로써 역할)

둘 사이의 차이

1. 상속
2. 연관관계
3. 데이터 타입
4. 데이터 식별 방법

서로 맞지 않다!

Album을 저장할 때

1. 객체 분해
2. 앨범의 데이터는 Album에
3. 아이템의 데이터는 Item 에

Album을 조회할 때

1. 각각의 테이블에 따른 조인 SQL 작성...
2. 각각의 객체 생성...
3. 상상만 해도 복잡
4. 더 이상의 설명은 생략한다.
5. 그래서 DB에 저장할 객체에는 상속 관계 안쓴다.

자바 컬랙션에 저장하거나 조회할땐?
그냥 add 나 get 사용.

연관관계도 다름.

• 객체는 참조를 사용: member.getTeam()
• 테이블은 외래 키를 사용: JOIN ON M.TEAM_ID = T.TEAM_ID

그래서 객체를 테이블에 맞춰 설계하기도 함.

객체를 참조로 들어가는게 더 맞긴함..
그럼 어떻게 조인하냐?
Member 에 Team 이 있을 때 Team 의 Id 를 꺼내서!

이 연관관계 조회하는 코딩

SQL 을 사용하면 처음 실행하는 SQL 에 따라 탐색 범위가 결정되어 버림.
Join 을 한 것만 조회할 수 있기 때문..

이러면 엔티티 신뢰 문제가 발생한다.
맴버를 조회했을 때 맴버 객체 안에 팀이 있을지, 오더가 있을지 알려면 SQL을 다 확인해봐야함.
-> 코드로 믿을 수 없게됨
그렇다고 모든 객체를 다 연결해서 조회하기엔 낭비임.

진정한 의미의 계층 분할이 어렵다! (물리적으론 되어있지만, 논리적으론 되어있지 않음)

SQL 에서 처리하는 것과 자바에서 처리하는게 결과가 다르다..!

연관관계를 만들수록 맵핑 작업만 늘어남!

객체를 자바 컬랙션 저장하듯 DB에 저장할 수 없을까??

ORM 개념2 - JPA 소개

JPA : Java Persistence API
자바 진영의 ORM 기술 표준

기술 표준 : 인터페이스!

ORM ?

• Object-relational mapping(객체 관계 매핑)
• 객체는 객체대로 설계
• 관계형 데이터베이스는 관계형 데이터베이스대로 설계
• 둘 사이의 차이를 ORM 프레임워크가 중간에서 매핑
• 대중적인 언어에는 대부분 ORM 기술이 존재

JDBC API 를 직접 쓰는게 아니라, JPA 를 쓰면 얘가 JDBC API 를 써서 SQL 전달함.

Member 객체를 JPA 에 넘겨주면
분석, SQL 생성해 JDBC API 사용해 동작하며 패러다임 불일치 해결함.

마치 자바 컬랙션 조회하듯 조회 가능함.

예전에도 자바에 ORM 인 EJB 가 있었는데 하이버네이트 라는 오픈소스를 새로 만들어 탄생.

성숙기가 와서 필요한 기능이 웬만한건 다 만들어져있음.

JPA를 왜 사용해야 하는가?

• SQL 중심적인 개발에서 객체 중심으로 개발
• 생산성 (JPA 가 할 일, 개발자가 할 일 구분되어 생산성 증가)
• 유지보수
• 패러다임의 불일치 해결
• 성능
• 데이터 접근 추상화와 벤더 독립성
• 표준

생산성 - JPA와 CRUD
• 저장: jpa.persist(member)
• 조회: Member member = jpa.find(memberId)
• 수정: member.setName(“변경할 이름”) (컬렉션을 생각하면 된다. 꺼내서 바꾸기만 하면 반영됨)
• 삭제: jpa.remove(member)

JPA 는 필드만 추가하면 됨. SQL 은 JPA 가 처리.

JPA와 패러다임의 불일치 해결
1.JPA와 상속
2.JPA와 연관관계
3.JPA와 객체 그래프 탐색
4.JPA와 비교하기

JPA 가 상속관계에 따라 쿼리 2번 날림.

조회하려면 앨범과 아이템을 조인해야함 이를 JPA 가 알아서.

연관관계를 다 해준다? 이게 어떻게 된거지??
이를 통해 신뢰할 수 있는 엔티티가 완성.

자바 컬렉션처럼 동작함!

JPA = Collection!

JPA 는 애플리케이션과 디비 사이에 있는 계층, 이에 따라 두가지 기능 가질 수 있음

1. 캐시
2. 버퍼링 라이트?
   이를통해 성능 최적화

두번째 조회한건 SQL 을 날리지 않음.

SQL 을 모으다가 커밋? 모아서 한번에 보내서 성능 최적화.

맴버에 있는 팀을 사용할지 안할지 모르니, 실제 사용할 때 지연로딩.
거의 같이쓰는 경우엔 설정을 해두면 즉시로딩도 가능

JPA 설정

spring-boot-starter-data-jpa 라이브러리를 사용하면 JPA와 스프링 데이터 JPA를 스프링 부트와 통합하 고, 설정도 아주 간단히 할 수 있다.

build.gradle 에 다음 의존 관계를 추가한다.

//JPA, 스프링 데이터 JPA 추가
implementation 'org.springframework.boot:spring-boot-starter-data-jpa'

이걸 쓰면 JDBC Template 은 없어도 됨.
라이브러리에 하이버네이트와 persistence , SpringDataJPA 도 추가됨

• hibernate-core : JPA 구현체인 하이버네이트 라이브러리
• jakarta.persistence-api : JPA 인터페이스
• spring-data-jpa : 스프링 데이터 JPA 라이브러리

application.properties

#JPA log
 logging.level.org.hibernate.SQL=DEBUG
 logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE

• org.hibernate.SQL=DEBUG : 하이버네이트가 생성하고 실행하는 SQL을 확인할 수 있다. (하이버네티으 = JPA)
• org.hibernate.type.descriptor.sql.BasicBinder=TRACE : SQL에 바인딩 되는 파라미터를 확인 할 수 있다.
• spring.jpa.show-sql=true : 참고로 이런 설정도 있다. 이전 설정은 logger 를 통해서 SQL이 출력된다. 이 설정은 System.out 콘솔을 통해서 SQL이 출력된다. 따라서 이 설정은 권장하지는 않는다. (둘다 켜면 logger , System.out 둘다 로그가 출력되어서 같은 로그가 중복해서 출력된다.)