⚡ 생각대로 살지 않으면 사는대로 생각한다.
⚡ 나는 어차피 잘 될 놈이다. 이미 잘 되고 있고, 계속해서 잘 되고 있다.

---

JPA

• Java Persistence API
• 자바 진영의 ORM 기술 표준

ORM

• Object-relational mapping(객체 관계 매핑)
  • 객체는 객체대로 설계
  • 관계형 데이터베이스는 관계형 데이터베이스대로 설계
  • ORM 프레임워크가 중간에서 매핑
• 대중적인 언어에는 대부분 ORM 기술이 존재

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

• JAVA 애플리케이션이 DB를 사용하기 위해선 원래 JDBC API를 써야하는데, 이를 개발자가 하는 것이 아니라 단지 JPA가 대신 해주는 것뿐.

---

JPA 동작 - 저장

• Member객체를 MemberDAO로 넘기면,
  • MemberDAO가 Member 엔티티(Entity:객체)를 저장해달라고 JPA로 던진다.
  • 엔티티를 받은 JPA가 알아서 Member객체를 분석
  • INSERT SQL을 생성
  • JDBC API를 이용해서, DB에 쿼리를 날려줌.
  • 패러다임의 불일치를 해결해줌.

---

JPA 동작 - 조회

• JPA로 MemberId를 던지면,
  • Member 객체를 분석,
  • SELECT 쿼리를 생성,
  • JDBC API를 이용해서 DB쿼리를 날림
  • ResultSet 매핑과 동시에 패러다임 불일치를 해결
• 결과적으로 Entity Object를 만들어서 반환

---

JPA 소개

자바 진영에서 EJB의 두 가지 큰 기능

• EJB - 컨테이너
• EJB - 엔티티 빈
  • JPA의 사실상 출발점
  • 개발자들이 거의 사용하지 않음.
    • 기술이 복잡하고 어렵고, 성능도 좋지 않았음.
  • EJB 사용하던 개발자가 빡쳐서 하나의 오픈소스를 만들었는데, 그것이 하이버네이트.
  • EJB를 만들었던 Java 진영에서 반성해서 하이버네이트를 개발했던 개빈 킹을 섭외해서 만든 자바 진영 명세 표준을 만들었는데, 이것이 JPA이다.

💡 참고!
EJB도 JPA처럼 객체를 저장 ,조회 해달라고 하면 해주는 것

---

JPA는 표준 명세

• JPA를 구현한 하이버네이트, EclipseLink, DataNucleus 중 80%~90%이상이 하이버네이트를 사용한다.

---

JPA 버전

---

JPA를 왜 사용해야 하는가?

생산성

• persist의 의미가 영구 보관을 의미
• 자바 컬렉션에서 객체를 저장하고, 수정하고, 삭제하듯이, DB정보를 간단하게 저장, 수정, 삭제함.

유지보수

• 어떤 필드를 추가해야한다면, 일일이 다 쿼리문 찾아가면서 추가해줘야 했고, 까먹으면, 중간에 퇴근하다가 회사 들어가야했지만,

• JPA를 이용하면, 필드만 추가하면 알아서 해결해준다.

---

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

1. JPA와 상속 - 저장
   

• 위와 같은 설계를 하게되면, insert 쿼리를 Item과 Album에서 날리는데, insert 쿼리를 총 두번을 넣어줘야 한다.

• 그런데 JPA를 이용하면 개발자는 한 줄만 추가해주면 된다.

2. JPA와 상속 - 조회
   

• 원래는 Item과 Album을 join한 다음에 가져와야 되는데, JPA에서는 코드 한 줄만 추가해주면, 알아서 join하고, 분석해서 결과를 반환해준다.

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

• 연관관계를 설정하면, 원래 외래키 값을 넣고 해야하는데, JPA에서는 .으로 참조가 가능하다. 마치 객체를 참조하듯이..
• 그리고 쿼리 조인시 성능최적화까지 고려해준다.

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

• SQL 중심적인 개발을 하게되면, Entity를 신뢰하기 많이 어려웠지만, JPA를 이용하면, 지연 로딩이라는 기술로 엔티티를 신뢰할 수 있게 된다.

JPA가 관리하는 객체를 Entity라고 한다.

JPA와 비교하기

• Java 컬렉션에서 같은 객체를 비교하면, 같다고 나오는 것 같이, JPA도 동일한 트랜잭션에서 조회한 엔티티라면, 같음을 보장한다.

JPA의 성능 최적화 기능

1차 캐시와 동일성 보장

• 종단에 있는 두 가지 기술의 중간에 하나의 기술이 존재하게되면, 성능상 이점을 얻을 수 있는 찬스가 있다.
  • 모아서 보낼 수 있는 BufferWriting이 가능
  • 캐싱 즉, 조회할 때 이미 조회된 것을 중간에서 쉽게 조회하여 결과를 반환함.

• JPA가 중간에 존재하는 기술이기 떄문에 가능함.

• 위의 그림내용

  • jpa.find(Memebr.calss, memberId);에서 memberId로 Member 객체를 찾게되면, JPA가 SQL을 날려서 조회한 Member객체를 반환해준다.
  • 그런데, 한번 더 jpa.find(Memebr.calss, memberId); 이 코드를 이용해서 Member객체를 조회하려고 하면 SQL을 날리는 게 아니라,
    처음 SQL을 날려서 얻은 Member Entity를 JPA가 캐싱해놓는데,
    두 번째 조회시 처음 SQL을 통해서 얻어서, 캐싱해놓은 Member 객체를 반환한다.
  • 그래서 같은 객체임을 확인할 수 있음.

트랜잭션을 지원하는 쓰기 지연 - INSERT

• 데이터를 계속 insert를 이용해서 보내는 것이 아니라, Buffer writing을 이용해서 insert sql을 모아놨다가 commit을 할 때, 한 번에 DB에 날려서 비용을 줄일 수 있다.

트랜잭션을 지원하는 쓰기 지연 - UPDATE

• 본 강의에서 자세히 다룰 예정..

지연 로딩과 즉시 로딩

• 연관관계가 매핑된 Team, Member가 있을 때, member를 조회할 때, Team 참조하는 줄 알았는데, 실상 Team을 잘 참조하지 않을 때, 연관관계를 꼭 같이 땡겨올 필요가 없다. 그러다 어쩌다 실제 Team이 사용될 때, 지연 로딩이 진행되어 Team을 얻어온다.

• Team과 Memebr가 늘 참조할 때,즉시 로딩을 이용해서 연관된 객체를 같이 땡겨올 수 있도록 한다.

• JPA는 지연 로딩과 즉시 로딩을 둘 다 지원한다.
  

---

참고 글
개빈 킹 - https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=rahmapoto&logNo=220822021960