[JPA] 1.JPA 소개

[JPA] 1.JPA 소개

 

0. 들어가며

JPA가 실무에서 어려운 이유

1) 객체와 테이블 올바르게 맵핑하고 2) 설계하는 법을 몰라서

---

1. SQL 중심적인 개발의 문제점 

Application은 객체지향

Database는 관계형

 

+ 상품, 주문마다 CRUD를 다 만들어야함

+ 객체에 필드 하나 추가하면 쿼리문을 다 고쳐야함

 

패러다임의 불일치

- 객체 지향 프로그래밍은 추상화 / 캡슐화 / 정보은닉 / 상속 / 다형성 등 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 제공

 

객체를 관계형 데이터베이스에 저장

[객체] - [sql 변환] - [RDB]

sql 변환 = sql 맵퍼가 개발자의 역할

 

(a) <<< 상속관계 >>>

- Album 저장

1) 객체 분해

2) INSERT INTO ITEM

3) INSERT INTO ALBUM

 

- Album 조회

1) 각각의 테이블에 따른 조인 SQL 작성

2) 각각의 객체 생성

-> 상상만해도 복잡

 

그래서 DB 저장할 객체에는 상속 관계를 쓰지 않음!!

 

자바 컬렉션에 저장한다면?
list.add(album);

자바 컬렉션에서 조회하면? : 부모 타입으로 조회 후 다형성 활용

Item item = list.get(albumId);

 

(b) <<< 연관관계 >>>

- 객체는 참조를 사용 : member.getTeam()

- 테이블은 외래 키를 사용 : JOIN ON M.TEAM_ID = T.TEAM_ID

 

아래처럼 객체를 테이블에 맞추어 모델링

아래는 객체다운 모델링

하지만 이렇게 하면 인서트 쿼리 / 조회 가 까다로워짐

인서트 -> TEAM_ID 칼럼을 넣을때 member.getTeam().getId(); 식으로 해야함

조회 -> SQL JOIN으로 멤버 가져와서 멤버 팀 각각 넣어주고 관계 설정까지 해서(member.setTeam(team))  return 

 

자바 컬렉션에서 관리한다면?

list.add(member);

Member member = list.get(memberId);

Team team = member.getTeam();

 

(c) <<< 객체 그래프 탐색 >>>

- 객체는 자유롭게 객체 그래프를 탐색할 수 있어야한다

 

엔티티 신뢰 문제

-> DAO에서 member 객체 가져왔는데 해당 member객체에서 member.getOrder() 등 할 수 있을까?

-> DAO에서 find 메서드가 어떻게 설계되었는지를 봐야겠다는 생각을 하게됨

 

모든 객체를 미리 로딩할 수는 없다

- 상황에 따라 동일한 회원 조회 메서드를 여러번 생성한다면 memberDAO.getmember/member with order 등등 메서드를 다 만들어줘야함...

 

계층형 아키텍처 - 진정한 의미의 계층 분할이 어려움

 

(d) <<< 비교하기 >>>

똑같은 데이터베이스의 결과를 객체 각각 생성해서 비교하면 분명히 다른 객체라고 인식한다

하지만 자바 컬렉션에서 list.get(memberId)라고 해서 생성한 두개의 member 객체는 동일하다!

 

결론) 객체답게 모델링 할수록 맵핑 작업만 늘어남...

-> 객체를 자바 컬렉션에 저장하듯이 DB에 저장할 수는 없을까?

 

= JPA(Java Persistentce API)

---

2. JPA 소개

JPA?

- Java Persistence API

- 자바 진영의 ORM 기술 표준

 

ORM?

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

- 객체는 객체대로 설계

- 관계형 데이터베이스는 관계형 데이터베이스대로 설계

- ORM 프레임워크가 중간에서 맵핑

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

 

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

 

JPA 동작 - 저장, 조회

저장

조회

JPA 소개

EJB : 엔티티 빈 (자바 표준) -> 하이버네트 (오픈 소스) -> JPA (자바 표준)

 

JPA는 표준 명세

- 인터페이스의 모음

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

- 하이버네이트, EclipseLink, DataNucleus

 

JPA를 왜 사용해야 하는가?

- SQL 중심적인 개발에서 객체 중심으로 개발

- 생산성

- 유지보수

- 패러다임의 불일치 해결

- 성능

- 데이터 접근 추상화와 벤더 독립성

- 표준

 

1) 생산성 - JPA와 CRUD

- 저장 : jpa.persist(member)

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

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

- 삭제 : jpa.remove(member)

 

2) 유지보수

- 기존: 필드 변경시 모든 SQL 수정

- JPA : 필드만 추가하면됨, SQL은 JPA가 처리

 

3) JPA와 패러다임의 불일치 해결

(a) JPA와 상속

[저장]

- 개발자가 할 일 : jpa.persist(album);

- 나머진 JPA가 처리 : INSERT INTO ITEM... / INSERT INTO ALBUM...

 

[조회]

- 개발자가 할 일 : Album album = jpa.find(Album.class, albumId);

- 나머진 JPA가 처리 : SELECT I.*, A.* FROM ITEM I JOIN ALBUM A ON I.ITEM_ID = A.ITEM_ID

 

(b) JPA와 연관관계

- 연관관계 저장 : member.setTeam(team); / jpa.persist(member);

 

(c) JPA와 객체 그래프 탐색

- 객체 그래프 탐색 : Member member = jpa.find(Member.class, memberId); / Team team = member.getTeam();

 

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

class MemberService {
  ...
  public void process() {
    Member member = memberDAO.find(memberId);
    member.getTeam();
    member.getOrder();.getDelivery();
  }
}

 

(d) JPA와 비교하기

String memberId = "100";
Member member1 = jpa.find(Member.class, memberId);
Member member2 = jpa.find(Member.class, memberId);

member1 == member2 //같다

* 동일한 트랜잭션에서 조회한 엔티티는 같음을 보장

 

4) JPA의 성능 최적화 기능

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

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

- DB isolation level이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장

-> jpa.find 여러개라도 sql조회 한번만 됨!!! (같은 트랜잭션안에서)

 

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

[INSERT]

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

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

transaction.begin(); //트랜잭션 시작

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);
// 여기까지 INSERT SQL 보내지 않음

// 커밋하는 순간 데이터베이스에 INSERT SQL 모아서 보냄
transaction.commit();

 

[UDPATE, DELETE]

- UPDATE, DELETE로 인한 로우(ROW)락 시간 최소화

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

transaction.begin();

changeMember(memberA);
deleteMember(memberB);
// 비즈니스 로직 수행() - 비즈니스 로직 수행 동안 DB 로우 락이 걸리지 않음

// 커밋하는 순간 데이터베이스에 UPDATE, DELETE SQL 보냄
transaction.commit();

 

(c) 지연 로딩(Lazy Loading), 즉시 로딩

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

- 즉시 로딩 : JOIN SQL로 한번에 연관된 객체까지 미리 조회

 

지연로딩

Member member = memberDAO.find(memberId); 
Team team = member.getTeam();
String teamName = team.getName(); // 이때 프록시 초기화 (team데이터 가져와서 값 채워줌)

즉시로딩

Member member = memberDAO.find(memberId); // member team 같이 쓴다고 셋팅 해두면 즉시 로딩(조인해서 가져옴)
Team team = member.getTeam();
String teamName = team.getName();

 

ORM은 [객체]와 [RDB] 두 기둥 위에 있는 기술