JPA의 CRUD와 패러다임의 불일치

JPA에서는 CRUD를 아래와 같이 제공한다.

 

저장기능

@PersistenceContext //entityManager를 주입해줌. private EntityManager jpa; jpa.persist(member);

-> JPA가 객체와 매핑정보를 보고 적절한 Insert SQL을 생성해서 DB에 보내준다.

(매핑정보란 어떤 객체를 DB의 어떤 테이블에 관리할 지 정의한 정보)

 

조회기능

String memberId="helloJPA"; Member member = jpa.find(Member.class, memberId);

 

수정기능

Member member = jpa.find(Member.class, memberId); member.setName("이름변경");

수정기능은 객체를 조회해서 값을 변경하기만 하면 트랜잭션이 커밋될 때 DB에 update SQL이 전송된다. 

 

연관된 객체 조회

Member member = jpa.find(Member.class, memberId); Team team - member.getTeam();

 JPA는 연관된 객체를 사용하는 시점에 적절한 select SQL을 실행한다.

즉, 그 이전의 시점에서는 굳이 연관 객체를 가져다놓지 않고, 사용할 때 DB에서 꺼내오는데, 이를 지연로딩이라 한다. 

 

패러다임의 불일치

기본적으로 JAVA는 객체지향 프로그래밍으로 추상화, 캡슐화, 정보은닉, 상속, 다형성 등을 사용한다. 이에 반해 관계형 데이터베이스는 데이터 중심으로 구조화 되어있고, 집합적인 사고를 요구한다. 그렇기 때문에 객체 간의 상속이나 참조 관계에 대한 표현이 불가능하다.

• 객체의 상속모델과 테이블의 모델   

Album 객체를 저장하려면 이 객체를 분해해서 다음 두 SQL을 만들어야 한다.

INSERT INTO ITEM .... INSERT INTO ALBUM ....

Movie 객체도 마찬가지다.

INSERT INTO ITEM ... INSERT INTO MOVIE ...

조회는 더 복잡하다. 

Album을 조회한다면 ITEM과 ALBUM테이블을 조인해서 조회하여 두 객체의 정보를 받아낸 후, ALBUM객체로 그 결과를 생성해야 한다. 이러한 과정들이 패러다임의 불일치를 해결하기 위해 소모되는 비용이다. 

만약 DB가 아니라 자바 내의 컬렉션으로 관리되었다면 부모자식이나 타입에 대한 고민없이 사용할 수 있다. (Item이라는 부모타입이 있기때문에) 

list.add(album); list.add(movie); Album album = list.get(albumId);

JPA와 상속

JPA는 상속과 관련된 패러다임 불일치 문제를 해결해준다. 개발자는 마치 자바 컬렉션에 객체를 저장하듯이 JPA에게 객체를 저장하면 된다.

 

• JPA를 사용한 ALBUM객체 저장

jpa.persist(album);

내부동작: INSERT INTO ITEM ...

                 INSERT INTO ALBUM ....

 

• JPA를 사용한 ALBUM 객체 조회

String albumId="id100"; Album album = jpa.find(Album.class, albumId);

내부동작: SELECT I.*, A.* FROM ITEM I JOIN ALBUM A ON I.ITEM_ID = A.ITEM_ID

 

복잡한 SQL 처리를 JPA가 다~ 알아서 해준다.