JPA는 왜 사용하는가?

JPA는 왜 사용하는가?

• 만약 JPA를 사용을 하지 않는다면 만약 (객체지향 언어를 사용한다고 하면) SQL를 객체답게 모델링 할 수록 매핑잡업만 늘어나게 된다. 예를 들면... CRUD 작업을 모든걸 계속해서 해줘야하는 듯한...?
• SQL 중심적인 개발에서 객체 중심으로 개발
• 생산성, 유지보수, 패러다임의 불일치 해결, 성능
• 데이터 접근 추상화와 벤더 독립성
• 표준

---

생산성 - JPA와 CRUD

• 저장 : jpa.persist(member);
• 조회 : Member member = jpa.find(memberId);
• 수정 : member.setName("변경할 이름");
• 삭제 : jpa.remove(member);

---

유지보수

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

---

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

JPA 연관관계 , 객체 그래프 탐색

• 연관관계 저장

  • Member.setTeam(team);
  • Spa.persist(member);

• 객체 그래프 탐색

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

---

JPA의 성능 최적화 기능

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

   • 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상
     • String memberId = "100";
       Member m1 = spa.find(Member.class, memberId); //SQL에서 가져옴
       Member m2 = spa.find(Member.class, memberId); //캐시에서 가져옴
       printLn(m1 == m2) //true. 결론: SQL이 1번만 실행이된다.

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

   • INSERT

     • 트랜잭션을 커밋할 때까지 INSERT SQL을 모은다.

     • transaction.begin(); //[트랜잭션 시작]
       em.persist(memberA);
       em.persist(memberB);
       em.persist(memberC); //여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.
       
       //커밋하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다.
       transaction.commit(); [트랜잭션] 커밋

3. 지연로딩(Lazy Loading)

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

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

     

SQL에서 객체지향언어인 자바처럼 객체를 자바 컬렉션에 저장 하듯이 DB에 저장할 수는 없을까???

• 결론적으로는 JPA를 만들었다..

---

JPA는 무엇인가??

• JPA는 인터페이스의 모음이다. -> 하이버네이트를 쓴다고 봐도 무방..?

1. ORM?

   • Object -relational mapping(객체 관계 맵핑)
   • 객체는 객체대로 설계
   • ORM 프레임워크가 중간에서 매핑

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

   

3. JPA 동작 - 조회

   

---

사진은 김영환님의 JPA기본편을 참고하였습니다.(인프런)