JPA
JPA가 탄생하기 전에는 iBatis와 같은 SQL 매퍼를 이용해서 DB쿼리를 작성했다. 그래서 실무에서는 실제로 개발하는 시간보다 SQL을 다루는 시간이 더 많았다고 한다.
'객체지향 프로그래밍을 하려고 왔는데 왜 테이블 모델링에만 집중하고 있지?'
객체를 단순히 테이블에 맞추어 데이터 전달 역할만 하는 개발은 분명 객체지향답지 않았다. 그래서 탄생한 것이 JPA라는 자바 표준ORM 기술이다.
Spring Data JPA
JPA는 인터페페이스로서 자바 표준 명세서이다. 인터페이스를 구현하기 위해서는 구현체가 필요한 데 대표적으로 Hibernate, Eclipse, Link등이 있다.
하지만 Spring에서 JPA를 사용할 때는 이 구현체들을 직접 다루진 않는다. 애플리케이션의 데이터 액세스 계층을 구현하는 것은 꽤 오랫동안 성가신 일이었다. 간단한 쿼리를 실행하고 pagination 및 auditing을 수행하려면 너무 많은 boilerplate 코드를 작성해야 한다. Spring Data JPA는 실제로 필요한 양으로 노력을 줄여 데이터 액세스 계층의 구현을 크게 개선하는 것을 목표로 만들어졌다.
그래서 Spring에서는 구현체들을 좀 더 쉽게 사용하고자 추상화시킨 Spring Data JPA라는 모듈을 이용하여 JPA 기술을 다룬다.
- Spring Data JPA → Hibernate → JPA
특징
- Spring 및 JPA기반의 Repo 구축을 위한 정교한 지원
- Querydsl 쿼리 지원 및 이에 따른 안전한 JPA 쿼리 처리
- 도메인 클래스의 투명한 감사
- pagination 지원, 동적 쿼리 실행, 맞춤형 데이터 액세스 코드 통합 기능
- @Query가 명시된 쿼리는 부트스트랩 시간에 유효성 검사
- XML 기반 엔티티 매핑 지원
- @EnableJpaRepositories을 지원하여 JavaConfig기반 저장소 구성
Hiberante vs Spring Data JPA
Hibernate와 Spring Data JPA는 큰 차이가 없는데 왜 굳이 Spring Data JPA를 사용해야 할까?
1.구현체 교체 용이성
Hibernate외에 다른 구현체로 쉽게 교체하기 위함이다. Hibernate에 대한 의존성을 낮추고 만약 새롭게 좋은 구현체가 나온다면 Spring Data JPA는 해당 구현체로 쉽게 교체할 수 있다.
- 실제 예시로는 자바 Redis 클라이언트가 Jedis에서 Lettuce로 대세가 넘어갈 때 Spring Data Redis를 사용하던 사람들은 쉽게 교체를 했다.
2. 저장소 교체 용이성
위와 마찬가지로 의존성을 낮추고 관계형 DB 외에 다른 저장소로 쉽게 교체하기 위함이다. 서비스 초기에는 관계형 DB로 모든 기능을 처리했지만, 점점 트래픽이 많아져 관계형 DB로는 도저히 감당이 안될 때가 올 수도 있다. 이때 MongoDB로 교체가 필요하다면 개발자는 Spring Data JPA에서 Spring Data MongoDB로 의존성만 교체하면 된다.
→ Spring Data의 하위 프로젝트들(Spring Data JPA, Spring Data Redis, Spring Data MongoDB 등등)은 기본적인 CRUD의 인터페이스(save(), findAll, findOne() 등)가 같다. 그러다 보니 저장소가 교체되어도 기본적인 기능은 변경할 것이 없기 때문에 Spring팀에서는 Hibernate를 직접 쓰는 것보다 Spring Data 프로젝트를 권장한다.
※참고