[섹션 1, 섹션 2, 섹션 3] 로마 제출합니다

[kbsat]

SQL 중심적인 개발의 문제점

• 우리는 객체지향 언어를 사용한다. DB는 관계형 DB를 주로 사용한다. 이렇게 됐을 때 객체지향 사상과 관계형 DB간의 차이가 발생한다.
  • 객체는 상속관계가 존재한다. 하지만 DB 테이블에는 슈퍼타입, 서브타입의 유사한 상속 관계는 있지만 객체의 상속관계와 일치하지 않는다. ( 객체에선 모든 필드가 자식 객체에 존재하는 반면 DB에선 서브 테이블은 추가적인 컬럼만 가지고 있을 뿐.. )
  • 그래서 객체만 썼을 때 컬렉션 이용해서 작업할 때보다 DB에서 작업이 훨씬 어려운 것..! ( INSERT 두번 막 하고... 조회 조인 해서 가져와서 매핑하고... )
  • 연관관계에서 객체는 참조를 이용하고 테이블은 외래키를 사용한다.
  • 우리 미션할 때 id를 필드로 가지는 방법과 객체를 필드로 가지는 방법이 있었는데.. 객체를 필드로 가지게 된다면 쿼리 작성 시 객체를 참조 참조 해서 id값을 끄집어내서 작업을 해야하는 불편함이 존재.. 그래서 보통 객체를 테이블에 맞춰서 모델링 하게 되버림..
  • 뭐 어찌저찌 넣는다 해도 조회할 때 싹 다 가져와야됨.. 이거 큰일임
  • 자바 컬렉션에서 같은 객체를 꺼낸다면 두 객체는 동일하다고 뜨지만 DB를 거치고 나면 rowMapper로 새로운 객체를 생성해서 내보내기 때문에 동일성 보장이 안됨.

위와 같은 미스매치가 반복... 그래서 나온게 JPA!

JPA

• Java ORM 표준 기술.
• 우리가 jdbc로 일일히 해줬던 작업들을 중간에서 대신 해줌
• 좀 더 객체지향적으로 개발할 수 있도록 도와준다.

장점

• DB, 객체 간의 패러다임 불일치 해결
• 신뢰할 수 있는 엔티티, 계층
• 연관관계, 객체 그래프 탐색 가능
• 동일 트랜잭션에서 조회한 엔티티는 동일성 보장

CRUD

• 저장 : persist
• 조회 : find
• 수정 : 더티체킹을 이용
• 삭제 : remove

성능 최적화 기능

• 1차 캐시와 동일성 보장
• 트랜잭션을 지원하는 쓰기 지연
• 지연 로딩

JPQL

• JPA가 제공하는 SQL을 추상화한 객체지향 쿼리 언어
• JPA를 사용하면서 검색 쿼리를 날릴 때 테이블이 아닌 엔티티 객체를 대상으로 검색하도록 도와줌
• setFirstResult(), setMaxResult()와 같은 페이징 기능도 쉽게 구현 가능

JPA를 이해하는데 가장 중요한 두가지

• 객체와 관계형 데이터 베이스 매핑
• 영속성 컨텍스트

영속성 컨텍스트

• 영속상태 : 영속성 컨텍스트에 관리되는 상태
• 비영속 상태 : 객체를 새로 만들었을 때와 같이 영속성 컨텍스트와 관계없는 상태
• 준영속 상태 : 영속성 컨텍스트에 저장되었다가 분리된 상태
• 삭제 : 삭제된 상태

영속성 컨텍스트의 이점

• 1차 캐시
• 동일성 보장
• 트랜잭션을 지원하는 쓰기 지연
• 변경 감지 ( 더티체킹 )

플러시

• 영속성 컨텍스트의 변경 내용을 DB에 반영하는 작업
• em.flush 로 직접 호출 가능 ( 직접 호출해도 1차 캐시는 안지워짐. 쓰기 지연 저장소의 쿼리들만 전송함 )
• 트랜잭션 커밋, JPQL 쿼리 실행 시 자동으로 호출됨
• 트랜잭션 단위 내에서 커밋 직전에만 동기화 하면 됨

준영속

• 영속을 떼버림
• 더티체킹 대상에서 빼고싶을 때, 1차 캐시에서 제거하고 싶을 때 등 쓰는 것 같음
• em.detach(entity) 특정 엔티티만 준영속상태로 변경
• em.clear() : 영속성 컨텍스트 비워버림
• em.close() : 영속성 컨텍스트 종료