SpringBoot JPA

JPA를 들어가기 전에 ORM부터 간단하게 알아보자.

실제 예제부터 먼저 돌려보고 나중에 이해해도 무방 할 것 같다.

# ORM이란?

 - Object-Relational Mapping (객체와 관계형데이터베이스 매핑, 객체와 DB의 테이블이 매핑을 이루는 것)

 - 객체가 테이블이 되도록 매핑 시켜주는 프레임워크 이다.
 - 프로그램의 복잡도를 줄이고 자바 객체와 쿼리를 분리할 수 있으며 트랜잭션 처리나 기타 데이터베이스 관련 작업들을 좀 더 편리하게 처리할 수 있는 방법
 - SQL Query가 아닌 직관적인 코드(메서드)로서 데이터를 조작할 수 있다.
ex) 기존쿼리 : SELECT * FROM MEMBER; 이를 ORM을 사용하면 Member테이블과 매핑된 객체가 member라고 할 때, member.findAll()이라는 메서드 호출로 데이터 조회가 가능하다.

# JPA란?

 - Java Persistence API (자바 ORM 기술에 대한 API 표준 명세)
 - 한마디로 ORM을 사용하기 위한 인터페이스를 모아둔 것 이라고 볼 수 있다.
 - 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스이다.
 - ORM에 대한 자바 API 규격이며 Hibernate, OpenJPA 등이 JPA를 구현한 구현체 이다. (ORM을 사용하기 위한 인터페이스를 모아둔 것)
 - Hibernate 이외에도 EcipseLink, DataNucleus, OpenJPA, TopLink 등이 있습니다.
※결국 인터페이스이기 때문에 JPA를 사용하기 위해서는 JPA를 구현한 Hibernate, EclipseLink, DataNucleus 같은 ORM 프레임워크를 사용해야 한다.

# Hibernate?

 - JPA를 사용하기 위해서 JPA를 구현한 ORM 프레임워크중 하나.
   (자바를 위한 오픈소스 ORM(Object-relational mapping) 프레임워크를 제공한다.)
 - Hibernate는 JPA 명세의 구현체이다. javax.persistence.EntityManager와 같은 JPA의 인터페이스를 직접 구현한 라이브러리이다.

 

 

우리가 알고 있는 Hibernate가 JPA의 구현체 인 것이다.

JPA Interface : 인터페이스
↓ 상속
Hibernate, EcipseLink, DataNucleus 등 : 구현체

 

 

1. JPA를 왜 사용할까?

Mybatis에 익숙해져서 잊어버렸을 수 있지만, 신규 개발시 또는 신규 컬럼이 추가되어 작업을 할때 등 CRUD SQL을 계속 반복적으로 사용한다.

신규 컬럼 하나만 추가되더라도 DTO(Vo, Domain 등), DAO 개발, 수정 작업이 매우 반복되는 작업임을 느꼈을 것이다.
(이러한 이유 때문에 쿼리를 자동생성해주는 툴들도 많이 생겼고, DB Query문으로도 자동 SELECT, INSERT 문을 생성하여 사용하기도 하였다.)

여러 SI시장의 경우 매우 복잡한 비즈니스 모델을 갖추고 있고 이에 따라 데이터 베이스 중심 설계(모델링, DB 테이블 설계)이 우선시되었고,
객체지향의 장점을 살리지 않고 단순히 객체 (DTO(VO, Domain 등))를 데이터 전달 목적으로 사용하기에 급급했다.

차츰 데이터 베이스 중심 설계의 단점을 개선하여 효율적으로 개발할수 있는 방법론에 관심이 많아지기 시작하였다. 이에 객체와 테이블을 매핑시켜주는 ORM이 주목 받기 시작했고, 자바에서는 JPA라는 표준 스펙을 정의하게 되었다.

그럼 어떤 장점과 단점이 있는지 정리 해보자.

 

▶ 1. 장점

1) 생산성이 뛰어나고 유지보수가 용이하다.(데이터베이스 중심 설계에서 객체 중심 설계로 변경됨에 따른) - 객체 지향적인 코드로 인해 더 직관적이고 비즈니스 로직에 더 집중할 수 있게 도와준다. - 객체지향적으로 데이터를 관리할 수 있기 때문에 전체 프로그램 구조를 일관되게 유지할 수 있다. - SQL을 직접적으로 작성하지 않고 객체를 사용하여 동작하기 때문에 유지보수가 더욱 간결하고, 재사용성도 증가하여 유지보수가 편리해진다. - DB컬럼이 추가될 때마다 테이블 수정이나 SQL 수정하는 과정이 많이 줄어들고, 값을 할당하거나, 변수 선언등의 부수적인 코드 또한 급격히 줄어든다. - 각각의 객체에 대한 코드를 별도로 작성하여 코드의 가독성도 올라간다.2) DBMS에 대한 종속성이 줄어든다. - DBMS가 변경된다 하더라도 소스, 쿼리, 구현 방법, 자료형 타입 등을 변경할 필요가 없다. - 즉 프로그래머는 Object에만 집중하면 되고, DBMS를 교체하는 작업에도 비교적 적은 리스크와 시간이 소요된다.   특히 요즘은 탈Oracle을 하여 MariaDB 등의 무료, 오픈소스 기반의 DMBS로 변경하는 기업이 늘고 있는데 이럴때 개발자들이 신경쓸 부분이 현저히 줄어든다.

 

▶ 2. 단점

1) 어렵다. - JPA의 장점을 살려 잘 사용하려면 학습 비용이 높은 편이다. - 복잡한 쿼리를 사용해야 할 때에 불리하다.   업무 비즈니스가 매우 복잡한 경우 JPA로 처리하기 어렵고, 통계처리와 같은 복잡한 쿼리 자체를 ORM으로 표현하는데 한계가 있다.   (실시간 처리용 쿼리에 더 최적화되어 있다고 봐도 무방할 것이다.) - 결국 기존 데이터베이스 중심으로 되어 있는 환경에서는 JPA를 사용하기도 어렵고, 힘을 발휘하기 어렵다. - 잘못사용할 경우 실제 SQL문을 직접 작성하는 것보다는 성능이 비교적 떨어질 수 있다. - 대용량 데이터 기반의 환경에서도 튜닝이 어려워 상대적으로 기존 방식보다 성능이 떨어질 수 있다.

결국 업무 환경, 이러한 장단점을 고려하여 Mybatis를 사용할지 JPA를 사용할지 의사결정에 참고하면 좋을 것 같다.

 

2. 스프링 데이터 JPA

# 스프링 데이터 JPA?

스프링 부트와 JPA만 사용해도 개발 생산성이 정말 많이 증가하고, 개발해야할 코드도 확연히 줄어듭니다. 
여기에 스프링 데이터 JPA를 사용하면, 기존의 한계를 넘어 마치 마법처럼, 리포지토리에 구현 클래스 없이
인터페이스 만으로 개발을 완료할 수 있습니다. 그리고 반복 개발해온 기본 CRUD 기능도 스프링 데이터
JPA가 모두 제공합니다.
스프링 부트와 JPA라는 기반 위에, 스프링 데이터 JPA라는 환상적인 프레임워크를 더하면 개발이 정말
즐거워집니다. 지금까지 조금이라도 단순하고 반복이라 생각했던 개발 코드들이 확연하게 줄어듭니다. 
따라서 개발자는 핵심 비즈니스 로직을 개발하는데, 집중할 수 있습니다.
실무에서 관계형 데이터베이스를 사용한다면 스프링 데이터 JPA는 이제 선택이 아니라 필수 입니다.