#JPA-1 SQL 중심적인 개발의 문제를 해결하기 위해 등장한 JPA

[출처] 인프런 김영한 강사님 -자바 ORM 표준 JPA 프로그래밍 기본

 

 

객체 지향 언어를 사용하면 자연스럽게 따라오는게 관계형 DB이다.

하지만 이를 구상하기 위해선 해당 구조에 맞는 지속적인 SQL을 생산해야하며

그로인해 무한반복되고 지루한 코드가 SQL 중심적인 개발이 된다.

 

자바 객체를 SQL로 SQL을 자바객체로 변경..

CLIENT의 요구가 늘어날 수록 수정해야하는 코드는 증가한다.

그 증가로 인해 개발자들은 SQL에 의존적인 코드를 벗어나기가 힘들다.

 

결국 <개발자 = SQL MAPPER>가 되는 것이다.

 

 

 

객체와 RDB의 차이

1.상속 - 객체에는 상속관계가 있음 , RDB는 X

2.연관관계 - 객체는 참조를 가지고 사용 , RDB는 PK FK로 JOIN 을 통해서 찾는다

3.데이터 타입

4. 데이터 식별 방법

 

 

내가 객체지향적으로 모델링하면 할수록 매핑작업만 늘어난다..

 

객체를 자바 컬렉션에 저장 하듯이

RDB에 저장할 수는 없을까?

해당 질문의 답이 JPA(Java Persistence API)이다.

 

 

JPA

- Java Persistence API

- 자바 진영의 ORM 기술 표준

 

ORM

- Object- relational mapping( 객체 관계 매핑)

1. 객체는 객체대로 설계

2. 관계형 데이터베이스는 관계형 데이텁베이스대로 설계

3. 둘의 차이들을 ORM 프레임워크가 중간에서 매핑

- 대중적인 언어에는 대부분 ORM 기술이 존재

 

JPA는 애플리케이션과 JDBC 사이에서 동작한다.

개발자가 직접 JPA를 쓰는게 아니라 JPA에 명령하면 JPA가 JDBC API 사용해서 SQL를 호출하고 DB가 만든 결과를 반환하는 구조이다.

 

 JPA 저장

JPA에게 MEMBER객체를 던지면 JPA가 MEMBER객체를 분석하고 적절한 SQL문을 생성하고 JPA가 JDBC API를 사용하여 SQL문을 DB로 보낸다.
중요한건!

1. 쿼리를 개발자가 만들지않고 JPA가 만들어준다는것.

2. 패러다임의 불일치를 해결해주는 것

JPA 조회

 JPA가 MAPPING정보를 바탕으로 SELECT 쿼리를 만들고 JDBC API를 통해 DB에 보내고 결과를 받은 ResultSet을 객체에다가 다 매핑을 하여 code 한줄로 만든다.

중요한건!

1. 패러다임의 불일치를 해결해주는 것

 

 

JPA는 표준 명세

 

-JPA는 인터페이스의 모음

-JPA 2.1표준명세를 구현한 3가지 구현체

-하이버네이트, EclipseLink , DataNucleus

JPA 2.1표준명세를 구현한 3가지 구현체

 

생산성 - JPA와 CRUD

저장: jpa.persist(member)

조회: Member member =jpa.find(memberId)

수정: member.setName("변경할 이름");

삭제: jpa.remove(member)

 

 

유지보수

필드 변경시 모든 SQL 수정

JPA는 필드만 추가하면된다, SQL은 JPA가 처리

 

JPA와 상속

 

기존 쿼리같은 경우는 item album 두번 쿼리가 들어가야하는데

jpa를 사용할 경우는 jpa.persist(album)을 하게되면 자체적으로 jpa가 insert into item, insert into album 두 번을 날린다.

 

 

신뢰할 수 있는 엔티티, 계층

JPA는 지연로딩이라는 기능이 있어서 실제 객체를 참조에서 사용하는 시점에 SQL에 나가서 DATA가 채워지는 구조가 있기때문에 자유로운 객체 그래프를 탐색할 수 있다. JPA를 통해가져오는 MEMBER객체를 믿을 수 있다.

 

 

JPA와 비교하기

 

JPA의 성능 최적화 기능

1. 1차 캐시와 동일성(identity)보장

2. 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)

3. 지연로딩(Lazy Loading)

 

 

1차 캐시와 동일성 보장

1. 같은 트랜잭션 안에서는 같은 엔티티를 반환 -약간의 조회 성능 향상

2. DB Isolation Level이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장

트랜잭션을 지원하는 쓰기 지연 -INSERT

1. 트랜잭션을 커밋할 때까지 INSERT SQL을 모음

2. JDBC BATCH SQL기능을 사용해서 한번에 SQL 전송

DB를 보낼때 원래 3번 SQL을 보내기 위해 NETWORK를 3번 왓다갓다 해야함.

JPA는 커밋하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다.

개발자가 DETAIL한 코드를 신경쓰지 않아도 된다.

 

트랜잭션을 지원하는 쓰기 지연 -UPDATE

1. UPDATE, DELETE로 인한 ROW LOCK 시간 최소화

2. 트랜잭션 커밋 시 UPDATE, DELETE SQL 실행하고, 바로 커밋

 

지연 로딩과 즉시 로딩

1. 지연 로딩 : 객체가 실제 사용될 때 로딩

2. 즉시 로딩 : JOIN SQL로 한번에 연관된 객체끼리 미리 조회

 

1. member객체를 꺼낼때 MEMBER랑 TEAM이 연관되어 있지만 MEMBER만 딱 가지고옴

2. member.getTeam으로 TEAM객체를 들고옴

3. 그런데 team.객체의 어떤값을 건들때 TEAM객체 값이 실제필요한 시점에 JPA가 TEAM에대한 쿼리를 날려서 DATA를 채워 채워진 결과인 TEAM을 가지고옴.

문제점 -쿼리를 2번탐 NETWORK를 두번 왓다거림.

만약 99%가 MEMBER를 조회할때 TEAM이 필수 로 따라온다고 하면 JPA 옵션 중에 MEMBER를 가지고올때 항상 TEAM을 가지고와 하는 옵션을 키면 쿼리가 TEAM 을 조인해서 가지고오는 옵션으로 바뀜.

이로인해 이후에 MEMBER랑 TEAM을 조회할때는 항상 LOADING되이있는 DATA를 가져다 쓰게 된다.

(옵션하는 켜고 끄고로 튜닝이 된다) -> 최적화가 필요할때만 튜닝가능.

 

 

ORM은 객체와 RDB 두 기둥위에 있는 기술이기때문에

JPA만 잘안다고해서 잘하는것도 아니고 RDB만 잘해도 잘하는 것이 아니다. 둘다 잘해야함.!!!!!!!!!!!!!!

 

[출처] 인프런 김영한 강사님  <자바 ORM 표준 JPA 프로그래밍 - 기본편>