김영한 (ORM 표준 JPA 프로그래밍 1)

 

JPA가 왜 쓰고 싶은가?

SQL 중심적인 개발의 문제점 = 객체답게 모델링 할 수록 매핑작업만 늘어난다.

객체에 필드추가하면 SQL에도 다 추가해야함 -> SQL에 의존적일 수 밖에 없다. 중간에 빼먹으면 큰일난다.

객체를 db에 넣기 위해 SQL Mapping을 개발자가 다 직접 해줘야한다.

 

객체와 RDB의 차이가 4가지 정도 존재

상속, 연관관계 , 데이터 타입, 데이터 식별 방법

상속 != 슈퍼타입 서브타입 테이블 관계

 

앨범에 데이터를 저장하고자 할떄 의 순서는 다음과 같다.

1. 객체 분해 -> 2. Insert into item.. , 3. insert into album

 

앨범에 데이터를 조회하고자 할때의 순서는 다음과 같다.

1.item 과 album을 join해서 불러온후에 -> 2.각각의 객체를 생성 -> 3.SQL Mapping을 다해줘야 한다.

 

 

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

db와 함께하면 매핑덕분에 굉장히 복잡함 , 위와 같이 한줄로 되지 않음

자바에서는 꺼낼떄마다 같은 key를 주면 같은 객체가 나오는데 db와 연관되면 조회 할때마다 매번 새로운 객체를 만들고 매핑된 것을 주기에 매번 다른 객체가 나오게 된다.

 

연관관계가 객체랑 db는 다르다

Team team 에다가 Team_id를 넣을 순 없다. 그래서 객체를 테이블에 맞추어 모델링을 하게 된다. 

즉 Team team 대신 Long teamId 이런식으로 Member 클래스를 만들게 된다.
조회시에 id를 얻어오고 id를 통해 Team을 조회하고 또 매핑하고 굉장히 어지러워 진다.

하지만 객체는 참조가(Team team) 들어 가는것이 더 맞다.

 

조회 쿼리를 날릴때 Order를 조회안했음으로 member에서 객체에서는 Order까지 뻗어나가지만 getOrder하면 null이 되는 어처구니없는 상황을 맞이 할 수 도 있다.

즉 서비스층에서 매번 DAO층의  SQL을 매번 확인을 해줘야한다. 엔티티  신뢰 문제가 생긴다. 

 

 

ORM (Object Relational Mapping)

객체는 객체대로 설계

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

ORM 프레임워크가 중간에서 매핑!!

JPA는 애플리케이션과 JDBC 사이에서 동작을 하게 됩니다.

jpa 도 결국 jdbc api 를 사용한다. 

저장을 할떄 쿼리를 JPA가 만들어준다. 위에서 언급한 패러다임의 불일치를 해결해준다.

JPA는 인터페이스의 모음이다. 아래의 3가지 구현으로 사용할 수 있게 된다. 주로 hibernate

JPA 는 성능최적화 기능이 잇다.

1. 1차 캐시와 동일성 보장

• 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상(굉장히 짧은시간 캐싱된다)
• DB isolation Level 이 Read Commit 이어도 애플리케이션에서 Repeatable Read 보장 = isolation level을 한단계 내려도 무방하다는 뜻이다.

2. 지연 로딩, 즉시로딩

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

즉시 로딩 = JOIN SQL로 한번에 연관된 객체까지 미리 조회 , 옵션을 주는 것으로 가능하다 이러면 네트워크 자원을 들 먹는다.