Spring Data JPA

JPA

스프링 레거시 프로젝트에서는 MyBatis를 이용해 Mapper를 만들고 직접 쿼리를 만들었다. 쿼리를 만들 때는 그 쿼리가 제대로 작동하는 지, 우선 해당 데이터베이스에서 직접 테스트하고, 코드에 적용했다. 간단한 CRUD 정도는 문제가 되지 않았지만, 그것도 쌓이면 나름 시간이 걸리는 일이다. 무엇보다 여러 개의 테이블을 join해서 작업하는 경우에는 쿼리를 짜는 데에만 꽤 오랜 시간이 걸렸다. 책에서도 "실제 개발 시간보다 SQL을 다루는 시간이 더 많았"다. "테이블 모델링에만 집중하고 객체를 단순히 테이블에 맞추는 기형적인 형태"였다고 설명한다.

내가 생각하기에 데이터는 거의 모든 것이다. 복잡하게 생각할 것도 없이 자명하다. 객체를 이용해 데이터를 운반하지만, 객체는 할 일을 마치면 가지고 있는 데이터와 함께 소멸한다. 따라서 데이터가 증발하기 전에 어딘가에 저장해두어야 한다. 그곳이 바로 데이터베이스다. 데이터베이스는 웹의 중심이다. 그런데 문제는 데이터베이스는 쿼리만 인식한다. 매번 기능에 맞는 쿼리를 만들어야 한다.

이렇게 하면 유지보수가 어려운 것은 물론이고 패러다임의 불일치가 발생한다. 데이터베이스는 어떻게 데이터를 저장할 것인가, 에 초점을 맞춘 기술이다. 반대로 객체지향은 메세지를 기반으로 기능과 속성을 한 곳에서 관리하는 기술이다.

다양한 객체 모델링을 데이터베이스는 구현할 수 없다. 그런데 중요는 하고. 점점 데이터베이스 모델링에만 집중하게 된다.

어떻게 하면 더 객체지향적으로 프로그래밍을 할 수 있을까? 이 문제의 해결책으로 JPA라는 자바 표준ORM(Object Relational Mapping)이 제시 되었다.

지향하는 바가 다른 두 개의 영역을 잇기 위한 기술이다. 객체지향적으로 프로그래밍을 하면, JPA는 관계형 데이터베이스에 맞게 해석하여 SQL을 대신 생성한다. 이렇게 하면 더 이상 데이터베이스에 종속적인 개발을 하지 않아도 된다.

Spring Data JPA

JPA(Java Persistence API)는 인터페이스로 자바 표준 명세서다. JPA를 사용하기 위해서 구현체가 필요하다.

• Hibernate

• Eclipse Link

• 그 외

스프링에서 JPA를 사용할 때 직접 구현체를 다루진 않는다. 더 쉽게, 더 추상화된 Spring Data JPA 모듈로 JPA를 다룬다.

관계는 이렇다.

JPA(인터페이스) <- Hibernate(구현체) <- Spring Data JPA

Hibernate와 Spring Data JPA를 사용하는 데에 큰 차이는 없다고 한다. 근데 왜 이렇게 분리해뒀을까?

• 구현체를 쉽게 바꾸려고
  • 하이버네이트가 아니라, 다른 구현체를 써야 하는데, 하이버네이트를 사용해서 JPA를 다뤘다면? 음...
• 저장소를 쉽게 바꾸려고
  • 관계형 데이터베이스 외에 다른 저장소로 쉽게 교체하기 위함