이 글은 강의 : 김영한님의 - "[스프링 DB 2편 - 데이터 접근 활용 기술]"을 듣고 정리한 내용입니다. 😁😁
👻 JPA 시작
JPA는 ORM 데이터 접근 기술을 제공한다.
⚽ MyBatis, JdbcTemplate은 SQL을 개발자가 직접 작성해야한다. 반면 JPA는 SQL를 개발자 대신 작성해준다.
중요한 것은 JPA. 스프링 데이터 JPA, Querydsl은 JPA를 편리하게 사용하도록 도와주는 도구라고 생각하면 된다. 이 챕터에서는 모든 내용을 다루지 않고, JPA와 스프링 데이터 JPA, 그리고 Querydsl로 이어지는 전체 그림을 볼 것이다.
그리고 이 기술들을 우리 애플리케이션에 적용하면서 자연스럽게 왜 사용해야 하는지, 그리고 어떤 장점이 있는지 이해할 수 있게 될 것이다.
- 이렇게 전체 그림을 보고 나면 앞으로 어떻게 공부해야 할 지 쉽게 접근할 수 있을 것!
🚀 ORM 개념1 - SQL 중심적인 개발의 문제점
지금은 애플리케이션은 객체로, 데이터 저장은 관계형 DB에 저장한다. 즉 객체를 관계형 DB에 관리하는 시대이다. 그런데 관계형 DB는 SQL만 알아들을 수 있다.
- 문제는 SQL 중심적인 개발이다.
⚽ SQL 의존적인 개발에서 벗어날 수 없다.
- SQL에 사용되는 많은 개발 쿼리들을 무한히 반복해서 작성해야 한다.
- 객체에 필드가 하나 추가되는 등의 변경점이 발생한다면, SQL을 모두 고쳐야 한다.
⚽ 객체 vs 관계형 데이터베이스의 패러다임이 불일치
- 객체와 관계형 데이터베이스의 차이가 발생한다. (상속, 연관관계, 데이터 타입, 데이터 식별 방법 등)
- 패러다임이 불일치 하기 때문에 개발자가 SQL Mapper 역할을 한다.
- 즉 객체를 관계형 데이터베이스에 저장해줘야 하는데 이걸 개발자가 해준다는 뜻...
- 현재는 객체를 테이블에 넣기 편하도록 모델링 한다. 객체관점에서는 올바르지 않다.
연관관계가 있는 경우 테이블에는 FK가 들어간다. 예를 들어 Team, Member 객체가 있고 Member가 Team에 속해있다고 가정해보자. 그렇다면 Member Table은 TeamID를 가지고 있을 것이다. 객체를 테이블에 넣기 좋게 만들기 위해서 자바 Member 객체에서도 TeamID를 가지고 있어야한다. 그렇지만 객체 관점에서는 올바르지 않다.
객체 관점에서는 Member 객체가 내부적으로 Team 객체를 포함하고 있는 관계가 더 올바르다.
- 처음 실행하는 SQL에 따라 탐색 범위가 결정된다.
어떤 테이블까지 Join 하느냐에 따라 탐색 범위가 한정된다. 탐색 범위가 한정되어있기 때문에 개발자는 DB에서 찾아온 객체가 어디까지 탐색 가능한지를 알고 서비스 로직을 작성해야한다.
반면 JPA를 사용하면, 처음 Join 쿼리를 사용한 것 이외에도 탐색 할 수 있게 된다.
Service 계층에서 Repository 계층에서 불러온 객체를 바탕으로 작업을 해야하지만, SQL 중심으로 작성한 경우 그렇게 작동할 수 없다. 왜냐하면 실제 나간 쿼리가 어느 필드까지 포함되는지 알아야 되기 때문이다. 따라서 SQL을 중심인 경우 물리적으로는 계층이 나누어져 있지만, 논리적으로는 계층이 나누어져 있지 않다고 볼 수 있다.
🚀 ORM 개념2 - JPA 소개
JPA는 Java Persistence API의 준말로
- 자바 진영의 ORM 기술 표준이다. 즉 이거 가지고 동작하는게 아니라 인터페이스라고 볼 수 있고 구현체가 따로 있어.
ORM ?
- Object-relational mapping(객체 관계 매핑)
- 객체는 객체대로 설계
- 관계형 데이터베이스는 관계형 데이터베이스대로 설계
- ORM 프레임워크가 중간에서 매핑 - 객체처럼 쓰게 해준다.
- 대중적인 언어에는 대부분 ORM 기술이 존재
✈️ 객체처럼 쓰게 해준다는 것이 핵심.
JPA는 애플리케이션과 JDBC 사이에서 동작한다.
JPA를 사용하면 내부에서 JDBC API를 통해 SQL을 전달하고 결과를 반환받고.. 위와 같이 동작한다 !
⚽ JPA 동작 - 저장
DAO를 Repository로 보면 돼, JPA에 객체를 넘겨주면 JPA에서 객체를 분석하고 SQL을 만들고 JDBC API를 사용해서 DB에 넣어준다. 그리고 패러다임 불일치를 해결해준다 ! (뒤에서 자세히.)
그리고 Repository에서 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)
- 위와 같이 매우 간편하고 생산성 증가 !
유지보수 관점 - SQL은 JPA가 처리
JPA는 필드만 추가하면 된다. SQL은 JPA가 처리해줌 !
JPA와 패러다임의 불일치 해결
🎈 JPA와 상속
🎈 JPA와 연관관계
🎈 JPA와 객체 그래프 탐색
🎈 JPA와 비교하기
기본적으로 JPA를 자바 컬렉션이라고 이해하면 편해 !!
근데 JPA를 공부하면 관계형 데이터베이스를 공부하지 않아도 되는가 ? 에 대한 질문이 나올 수도 있다.
-
이러면 안된다는 것을 알 것이다.. ORM은 객체, 관계형 DB 모두 중요하고, 둘 다 잘 알아야만 가능하다.
-
또한 ORM을 배우더라도 실무에서 장애는 90퍼센트 이상 DB에서 발생한다. 그렇기 때문에 관계형 BD에 대해서는 매우 깊이 있게 공부해야 한다!!
(사실 JPA는 내용이 복잡하지 코드는 얼마 안돼!)
