스프링 부트에서 JPA 사용하기 (1)

ORM : Object Relational Mapping

JPA를 이해하기전 알고 가야할 것은 ORM이라는 개념입니다.

 

• 객체가 테이블이 되도록 매핑 시켜주는 프레임워크
• 객체와 DB의 테이블 매핑을 이루는 것
• 자바 객체와 쿼리를 분리해 프로그램의 복잡도를 줄임
• 트랜잭션(Transaction)과 같은 DB관련 작업들을 좀 더 편리하게 처리할 수 있는 방법
• 쿼리가 아닌 직관적인 메서드로 데이터를 조작할 수 있음

JPA : JAVA Persistance API

객체지향 프로그래밍을 객체지향 프로그래밍 답게 개발할 수 있는 자바 표준 ORM(Object Relational Mapping)입니다.

 

• 자바 ORM 기술에 대한 표준 명세
• ORM을 사용하기 위한 인터페이스를 모아둔 것
• 자바 어플리케이션에서 RDB를 사용하는 방식을 정의한 인터페이스
• ORM에 대한 자바 API 규격으로 Hibernate, OpenJPA 등이 JPA를 구현한 구현체

Hibernate는 JPA를 사용하기 위해 구현한 구현체 중 하나로 JPA 인터페이스를 상속 받아 구현한 것이라고 보면 됩니다.

 

기존 iBatis가 아닌 JPA가 사용되고 있는 이유를 알아보겠습니다. MyBatis에서는 SQL 쿼리문을 작성해 DB와 CRUD 작용을 하였습니다. 허나 SQL 중심 개발에는 아래와 같은 문제가 존재합니다. (참고로 MyBatis는 ORM이 아닌 SQL Mapping에 가깝다고 보시면 됩니다.)

 

[등장배경] SQL 중심 개발의 문제점

 

• 무한 반복되는 지루한 코드
  
  CRUD 기능을 추가하고자 할 때, 쿼리를 추가로 짜야합니다. 또한 자바 객체를 SQL로 변경하고, DB에서 받아온 결과를 객체로 변환하는 등의 반복적인 작업을 진행해야 합니다.
  
  
• 비효율적인 유지보수
  
  만약 필드를 추가할 경우 해당 Entity와 관련된 쿼리를 모두 수정해야 하는 작업을 해야합니다.
• 패러다임의 불일치
  
  RDB는 데이터를 어떻게 저장할지 초점이 맞춰진 기술이나, 객체지향 프로그래밍 언어는 메시지를 기반으로 기능과 소것ㅇ을 한 곳에서 관리하는 것에 초점이 맞추어 있습니다. 즉, 이 둘은 패러다임이 서로 달라 여러 문제가 발생하는데 이를 패러다임 불일치라고 합니다.
  
  가장 큰 예시로 필요한 데이터를 조회하기 위해 JOIN을 이야기할 수 있습니다.
  
  만약 A를 상속받는 B 객체, 그리고 1:n 관계를 갖는 A 테이블과 B 테이블 존재한다고 해보겠습니다. 이때, B를 조회하기 위해서는 A와 B를 JOIN하여 조회한 뒤, 그 결과를 B 객체로 생성해야 합니다.
  
  이는 패러다임 불일치에 따른 비용이라고 볼 수 있습니다.

JPA의 장점

 

• 생산성이 뛰어나며 유지보수가 용이함
  
  SQL 중심 개발에서 객체중심 개발로 변경되며 유지보수가 자연스럽게 유지보수가 용이해졌습니다. 상세한 이유는 다음과 같습니다.
  
  - 객체지향적인 데이터 관리로 전체 프로그램 구조를 일관되게 유지할 수 있습니다.  
  
  - SQL을 사용하지 않고 객체를 사용해 동작하기에 유지보수가 더욱 간결하고, 재사용성이 높아졌습니다.
  
  - 쿼리 수정이 과정이 줄어들며, 값을 할당하는 등 부수적 코드 또한 감소합니다.
  
  - 각 객체에 대한 코드를 별도로 작성해 코드의 가독성이 증가합니다.
  
  
• DBMS에 대한 종속성 감소
  
  DBMS가 변경되어도 소스, 쿼리, 구현방법 등을 변경할 필요가 없습니다. 즉, 개발자는 객체에만 집중할 수 있게 됩니다.
  
  
• 패러다임의 일치
  
  RDB와 객체지향 프로그래밍 언어는 서로 지향하는 바가 다릅니다. 즉, MyBatis를 도입해 웹 애플리케이션을 개발다보면 다양한 객체 모델링을 DB로 구현할 수 없어 데이터베이스 모델링에 집중하는 문제가 발생합니다.
  
  JPA는 관계형 데이터베이스에 맞게 메서드를 통해 SQL을 대신 생성해 실행함으로 중간에서 패러다임을 일치시켜줍니다.
  이로 SQL에 종속적인 개발을 하지 않아도 된다는 장점이 있습니다.
  
  

JPA의 단점

 

• 높은 러닝커브
  
  JPA의 장점을 잘 살려 활용하기 위한 학습 난이도가 높은 편입니다. 이를 위해서는 객체지향 프로그래밍뿐만 아니라 RDB를 모두 이해해야하기 때문입니다.
  
  
• 불리한 복잡한 쿼리 처리
  
  통계와 같은 복잡한 쿼리를 ORM으로 표현하는 것에 한계가 있습니다. JPA는 실시간 처리용 쿼리에 좀 더 적합하다고 볼 수 있습니다.

 

Spring Data JPA

앞서 언급되었듯 JPA는 인터페이스로서 자바 표준명세서입니다. 인터페이스인 JPA를 사용하기 위해 구현체가 필요합니다.

대표적 구현체
Hibernate, Eclipse, Link 등

 

구현체를 쉽게 사용하기 위해 Spring Data JPA라는 모듈로 JPA 기술을 다룰 수 있습니다. Spring Data JPA 내부에서 구현체 매핑을 지원해주고 있습니다.

구현체의 관계
JPA <-- Hibernate <-- Spring Data JPA

 

여기서 Spring Data JPA를 사용하는 이유는 [구현체 교체의 용이성]과 [저장소 교체의 용이성] 두 가지가 존재합니다.

 

• 구현체 교체의 용이성
  
  Hibernate 외에 다른 구현체로 쉽게 교체하기 위함입니다.
  만약 다른 JPA 구현체가 대세로 떠오를 때, Spring Data JPA를 사용하고 있었다면, 이를 쉽게 교체할 수 있습니다.
  
  
• 저장소 교체의 용이성
  
  관계형 데이터베이스 외에 다른 저장소로 쉽게 교체하기 위함입니다.
  
  RDB를 많이 사용하지만, 트래픽이 이로 감당이 안 될 때 다른 DB로 교체해야할 필요가 있을 수 있습니다. 만약 교체하려는 DB가 MongoDB라면, Spring Data JPA에서 Spring Data MongoDB로 의존성만 교체하면 됩니다.

 

교체가 쉽게 이루어질 수 있는 이유는 Spring Data 하위 프로젝트들은 기본적인 CRUD의 인터페이스가 같기 때문입니다.

위와 같은 이유들로 Spring 팀에서는 Spring Data 프로젝트를 권장하고 있는 것입니다.