JPA의 등장 배경 - SQL 중심적인 개발의 단점
JPA를 사용하지 않을 경우, 다음과 같이 SQL 중심적인 개발의 단점을 마주치게된다.
- 개발자가 CRUD 쿼리문을 반복적으로 작성해야한다.
- 객체에 새로운 필드가 추가될 경우, 쿼리문을 모두 수정해야한다.
- 다음에 나오는 '자바의 객체 vs 관계형 DB의 테이블' 패러다임 차이로 인해, 객체와 테이블 간의 매핑작업이 복잡하다.
- 상속 : 객체 상속 관계 vs 테이블 슈퍼타입 서브타입 관계
- 객체 조회시 조인 쿼리가 자주 발생하므로, DB에 저장할 객체는 상속 관계를 쓰지않는다.
- 연관관계 : 객체의 참조 주소 저장 vs 객체의 PK를 저장하고 조회시 조인
- 객체를 DB에서 조회할 때, 객체 그래프 탐색을 위해 수행하는 객체 간의 관계 설정이 복잡하다.
- 객체 비교
- 테이블에서 객체를 두번 조회하여 비교해보면, 두 객체의 참조 주소가 다르기 떄문에 다른 객체로 판단한다.
JPA란?
자바 진영의 ORM(Object-Relational Mapping) 기술 표준으로, 자바 애플리케이션과 JDBC 사이에서 동작한다.
자바의 객체지향적인 특징을 살리면서 개발자가 수행해야하는 객체와 테이블 간의 복잡한 매핑과정 없이 DB를 간편하게 이용할 수 있도록 도와준다.
- 내부적으로 JDBC API를 사용한다.
- JPA는 hibernate, OpenJPA, EclipseLink 등 여러 구현체가 존재하는데, 주로 hibernate를 이용한다.
JPA를 사용해야하는 이유
- SQL 중심적인 개발에서 벗어나 객체 중심적으로 개발할 수 있다.
- 생산성이 향상된다.
- JPA는 자바 컬렉션에서 객체를 이용하는 방법과 유사하다.
- 유지보수가 간편하다.
- 객체에 새로운 필드가 추가되면, 개발자가 쿼리문을 다시 작성하지 않아도된다.
- 성능이 향상된다.
- 1차 캐시와 동일성(identity) 보장
- 트랜잭션을 지원하는 쓰기 지연
- 지연로딩을 지원한다.
Member
객체가 Team
객체를 필드로 가지고 있다고 가정하자.
Member
객체를 사용할 때 Team
객체도 같이 사용하는 경우가 적다면, 지연로딩 기술을 이용하여 Team
객체가 실제로 사용될 때 해당 객체를 DB에서 로딩한다.
- 초기에는 지연로딩으로 설정하고 즉시로딩이 성능에 유리하다고 판단되면 그때 변경하는 것이 성능에 유리하다.
- 표준 기술이다.
- 데이터 접근 추상화와 벤더 독립성
JPA의 단점
- 설계를 잘못할 경우, 속도 저하 문제가 발생한다.
- 복잡한 조회를 수행할 때는 별도의 튜닝을 위해 직접 쿼리를 작성해야한다. 따라서 쿼리 생성을 도와주는 조회용 프레임워크를 따로 사용하는 것이 좋다.
- 조회용 프레임워크 : Querydsl(추천), MyBatis, jook
Reference