[Spring Boot2][1] 1. JPA 소개

🏷 SQL 중심적인 개발의 문제점

SQL을 사용해 개발을 한다고 가정해보자!
기능을 추가하기 위한 테이블을 만들다 보면, 지루한 코드,,,,😅 가 반복되고 있다는 것을 스스로 느끼게 된다..^^

객체 CRUD에 필드를 추가하는 경우를 보자!

이처럼 쿼리를 한 땀 한 땀 수정해야 한다^^ 매우 귀찮^^

➡️ SQL에 의존적인 개발을 피하기가 어렵다!
➡️ 현실적인 대안은 바로 ❗️관계형 데이터베이스❗️를 사용하는 것이다.

✔️ 객체와 관계형 데이터베이스의 차이

1️⃣ 상속

각각의 테이블에 따른 조인 SQL 작성,, 각각의 객체 생성,, 상상만 해도 복잡해진다 😅
➡️ 객체와는 다르게 관계형 데이터베이스에서는 DB에 저장할 객체에는 상속 관계를 쓰지 않는다!!

2️⃣ 연관관계

• 객체는 참조를 사용 = member.getTeam()
• 테이블은 외래 키를 사용 = JOIN ON M.TEAM_ID = T.TEAM_ID
• 객체와 달리 테이블은 양방향 조인이 가능하다!!!

---

✔️ 객체를 테이블에 맞추어 모델링

그러나 이 방법은 뭔가 객체지향 스럽지 않다,, 멤버가 외래키 값을 가지는 것이 아니라 참조값을 가져야 하는게 아닐까🤔❓

✔️ 객체 모델링 저장

외래키 값이 없는 TEAM_ID 대신, member.getTeam().getId() 으로 참조해서 얻어오면 저장은 할 수 있다!

⬆️ 위의 방법처럼 저장한다고 했을 때 진정한 문제는 조회할 때 발생한다,,

✔️ 객체 모델링 조회

• 굉장히 번거로운 과정들😅
• 자바 컬렉션에서 관리한다 가정할 땐 매우 편리해 보이지만, DB에 넣을 때 문제가 복잡해진다.

✔️ 객체 그래프 탐색

⬆️ 위와 같이 객체는 자유롭게 객체 그래프를 탐색할 수 있어야 하는데 그렇지 못하다,,

⬆️ 바로 처음 실행하는 SQL에 따라 탐색 범위가 결정돼버리기 때문😂
이는 곧 엔티티 신뢰문제까지 이어질 수 있다!

안희,, 객체답게 모델링 할수록 매핑 작업만 늘어나는데,,, 어떡하라는 거죠,,,,^_^?

---

🏷 JPA 소개

객체답게 모델링 할수록 매핑 작업만 늘어나는데, 객체를 자바 컬렉션에 저장하듯이 DB에 저장할 수는 없을까🤔❓

그래서 나온 것이 ❗️JPA❗️

📌 JPA

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

📌 ORM

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

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

• JPA에게 명령을 하면 그 안에서 JDBC API가 동작을 한다!

✔️ JPA 동작 - 저장

• 여기서 사용되는 쿼리는 개발자가 아닌 JPA가 만들어준다!
• 패러다임의 불일치를 해결해준다❗️

✔️ JPA 동작 - 조회

✔️ JPA는 표준 명세

• JPA는 인터페이스의 모음
• JPA 2.1 표준 명세를 구현한 3가지 구현체
• 하이버네이트, EclipseLink, DataNucleus

---

🏷 JPA를 왜 사용해야 하는가?

• SQL 중심적인 개발에서 객체 중심으로 개발
• 생산성
• 유지보수
• 패러다임의 불일치 해결
• 성능
• 데이터 접근 추상화와 벤더 독립성
• 표준

✔️ 생산성 - JPA와 CRUD

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

✔️ 유지보수

1️⃣ 기존 : 필드 변경시 모든 SQL 수정

• 악덕 기획자가 갑자기 서비스 변경을 요구했을 때 하나하나 다 고쳐야 함 ㅠ

2️⃣ JPA : 필드만 추가하면 됨, SQL은 JPA가 처리

• 악덕 기획자가 괴롭혀도 쿼리를 손대지 않고 컬럼만 추가하면 됨!

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

1️⃣ 상속 - 저장

• 개발자가 구조에 대해 크게 신경쓰지 않고 쿼리를 날려도, JPA가 INSERT 쿼리를 두개로 쪼개서 만들어 줌

2️⃣ 상속 - 조회

• 개발자가 쿼리를 날리면 JPA가 알아서 JOIN해 결과를 반환해 줌

3️⃣ 연관관계, 객체 그래프 탐색

• 연관관계를 저장하면, JPA가 마치 자바 컬렉션에 넣은 것 처럼 가져올 수 있음

4️⃣ 신뢰할 수 있는 엔티티, 계층

• 객체 그래프를 자유롭게 탐색할 수 있음(=지연로딩)

✔️ 성능

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

• 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상
• DB Isolation Level이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장

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

• INSERT
  • 트랜잭션을 커밋할 때까지 INSERT SQL을 모음
  • JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송

• UPDATE
  • UPDATE, DELETE로 인한 로우(ROW)락 시간 최소화
  • 트랜잭션 커밋 시 UPDATE, DELETE SQL 실행하고, 바로 커밋

3️⃣ 지연 로딩(Lazy Loading)

• 지연 로딩 : 객체가 실제 사용될 때 로딩
• 즉시 로딩 : JOIN SQL로 한번에 연관된 객체까지 미리 조회

---

로드맵2 뿌시자!!!!!!!!!!!!!ㅇ우아ㅗ아앙!!!!!!!!!!!!!!!!!!!!!!!!