JPA란?

이 글에서 사용하는 DB는 관계형 데이터베이스를 편하게 사용할려고 일반적 DB처럼 말하고 있습니다.

참고 이글은 자바 ORM 표준 JPA프로그래밍을 읽고 정리한 글입니다.

JPA란 무엇인가?

자바 퍼시스턴스 API또는 자바 지속성 API(Java Persistence API, JPA)는 자바 플랫폼 SE와 자바 플랫폼 EE를 사용하는 응용프로그램에서 관계형 데이터베이스의 관리를 표현하는 자바 API이다.

기존에 EJB에서 제공되던 엔터티 빈(Entity Bean)을 대체하는 기술이다. 자바 퍼시스턴스 API는 JSR 220에서 정의된 EJB 3.0 스펙의 일부로 정의가 되어 있지만 EJB 컨테이너에 의존하지 않으며 EJB, 웹 모듈 및 Java SE 클라이언트에서 모두 사용이 가능하다. 또한, 사용자가 원하는 퍼시스턴스 프로바이더 구현체를 선택해서 사용할 수 있다.

출처:ko.wikipedia.org/wiki/%EC%9E%90%EB%B0%94_%ED%8D%BC%EC%8B%9C%EC%8A%A4%ED%84%B4%EC%8A%A4_API

자바 퍼시스턴스 API - 위키백과, 우리 모두의 백과사전

구글에 jpa가 무엇인지 검색하면 위키백과에 나오는 글이다. 즉 쉽게 말해 자바플랫폼과 관계형 데이터베이스의 관리를 도와주는 자바의 api이다. 자 이제 ORM이란것이 무엇인지 알아보자.

 

ORM이란?

데이터베이스와 객체 지향 프로그래밍 언어 간의 호환되지 않는 데이터를 변환하는 프로그래밍 기법이다. 객체 지향 언어에서 사용할 수 있는 "가상" 객체 데이터베이스를 구축하는 방법이다. 객체 관계 매핑을 가능하게 하는 상용 또는 무료 소프트웨어 패키지들이 있고, 경우에 따라서는 독자적으로 개발하기도한다.

출처:ko.wikipedia.org/wiki/%EA%B0%9D%EC%B2%B4_%EA%B4%80%EA%B3%84_%EB%A7%A4%ED%95%91

객체 관계 매핑 - 위키백과, 우리 모두의 백과사전

ORM은 쉽게 말해 객체와 관계형 데이터베이스를 매핑하는 방법이다. ORM이 무엇인지 알았다면 JPA를 ORM과 연관지어 쉽게 정의해 보겠다.

 

JPA는 자바진영을 대표하는 ORM의 표준이다. 즉 ORM을 사용하기 위한 JAVA API 규격이다.

자 그러면 이제 어떠한 의문이 들 것이다. 데이터베이스를 JDBC API를 사용해 SQL로 DB를 관리하면 되지 왜 JPA를 사용하는가? 그럼 먼저 JPA를 사용하지 않고 JDBC와 SQL로 사용하던 것들의 문제점을 살펴보자

SQL문제점?

자 그러면 이전에 JDBC로 SQL에 create를 할때를 생각해보자

1.create 쿼리문을 작성한다.

2.객체의 값을 하나하나 sql에 전달한다.

3.jdbc api를 사용해 SQL에 update해준다.

이러한 작업들을 통해 create가 된다. 하지만 DB에 저장하지 않고 자바진영에서 객체를 저장한다면 저렇게 사용하지 않고 객체그자체만 저장하면 끝이나는 작업이다.

SQL에 의존적 개발

만약 DB를 수정할 경우 SQL문을 바구고 소스코드를 바꾸고 많은 것을 바꾸고 확인해야한다. 에러가 날경우 결국 SQL을 열어서 사용된 쿼리문을 확인하여야만 에러를 고칠수 있다는 것이다. 이러한 방식은 결국 개발자가 Entity를 신뢰할 수 없게만들고 계층 분할이 어려워진다. 즉 SQL에 의존적인 개발을 하지 않을 수 없다는 것이다.

DB구조와 객체의 차이

왜 자바에서와 다르게 DB에서는 이렇게 많은 작업을 해야할까? 그 이유는 DB구조와 자바에서 사용하는 객체 구조가 다른 데이터 구조를 가지기 때문에 객체를 DB에서 직접 사용할 수 없기 때문이다. 그래서 우리는 이때동안 JDBC API와 SQL을 사용해서 객체를 변환하여 사용해왔다. 하지만 이러한 단순반복작업은 개발자들에게 너무 힘들고 지루한 작업이 될 것이다. 위에서 DB와 객체는 서로 다른 데이터 구조를 가지고 있다고 말했었다. 그럼 둘의 이러한 차이점이 왜 생겨났는지 알아보자.

DB:'데이터를 어떤식으로 저장할지?'

객체:'어떤방식으로 추상화를 하고 관리를 할지?' 

 

이렇게 DB와 객체의 주된 목적이 다르다. 쉽게 말하자면 객체는 상속,추상화,다형성 같은 개념을 가지지만 DB는 그러한 것들을 가지고 있지 않다. 이러한 차이에서 DB에 객체를 바로 저장하지 못하고 개발자들이 직접 하나하나 변환하는 작업이 필요했던 것이다. 특히 상속과 추상화가 사용된 객체 일수록 변환해야할 코드의 길이가 어마어마해진다.

쉽게말해 A라는 객체와 A를 상속받은 B라는 객체가 있다고 생각해보자. B를 저장하기 위해서는 A와 B를 둘다 만들고 각각의 데이터만 따로 저장하여야만 한다.

 

이 문제를 다루기 위해 우선 객체와 테이블간의 연관관계를 알아보자

연관관계

객체: 참조를 사용해서 다른 객체와 연관관계를 가지고 참조에 접근해서 연관된 객체 조회
테이블 : 외래 키를 사용해서 다른테이블과 연관관계를 가지고 조인을 사용해서 연관된 테이블을 조회

객체는 참조를 통하기에 단방향만 가능한 반면 , 테이블은 외래키 하나로 양방향 접근이 가능
=>참조를 사용하는 객체와 외래키를 사용하는 DB사이의 패러다임 불일치

 

이렇게 두개 사이의 연관관계만을 생각을 하더라도 DB와 객체의 차이점으로 패러다임 불일치가 일어나는 것을 볼 수 있다. 그렇다면 DB와 객체의 모델링을 어떻게 해야 할까? 결론부터 말하자면 객체는 객체답게 참조를 통해서 관계를 맺는 객체 지향 모델링을 해야한다. 그 이유를 알아보자.

객체를 테이블에 맞추어 모델링

객체를 테이블에 맞추어 모델링을 하면 객체안에 참조하는 객체가 있는 것이 아니라 객체 안에 참조하는 객체의 필드를 저장할 것이다. 그런데 이 객체의 필드에 문제가 있다. 테이블의 경우에는 양방향이 가능하기에 외래키의 값을 그대로 보관해도 되지만 객체의 경우 필드를 통해 연관된 객체를 찾을수없기 때문이다. 이러한 방식으로 모델링을 한다면 결국 객체지향의 특징을 잃어버리게 된다.

 

객체지향 모델링

따라서 객체는 객체를 통해 참조를 하며 찾을 수 있게 모델링을 해야한다. 물론 이렇게 모델링을 하면 객체는 참조를 통해 연관관계를 맺고 테이블은 외래키로 연관관계를 맺기 때문에 서로의 차이로 인한 변환을 개발자가 해주어야 한다. 물론 JPA에서는 이러한 것들도 편리하게 해결하며 패러다임의 불일치를 해결해 주었다.

계속하여 왜 JPA를 사용하여야 하는지의 문제점들을 말하고 있다. 물론 앞서 말한것들은 SQL을 잘 사용하면 극복할 수 있는 문제들이다. 그렇다면 연관관계와 관련하여 극복하기 어려운 패러다임 불일치의 문제들을 한번 살펴보자.

객체 그래프 탐색

객체에서 소속된 팀을 조회할 때는 다음처럼 참조를 사용해서 연관된 팀을 찾으면 되는데 이것을 객체 그래프 탐색이라고 한다. 객체는 마음껏 객체 그래프를 탐색할 수 있어야 하는데 과연 실제로도 그럴까?

정답은 NO이다. 처음실행하는 SQL에 따라 객체 그래프를 어디까지 탐색할 수 있는지가 정하지기 때문이다. 

즉 객체그래프탐색 범위를 알기 위해서는 직접 DAO를 열어서 SQL문을 확인해야 한다

=>SQL 의존적 개발

비교

DB는 기본키의 값으로 각 로우를 구분.

객체는 동일성 비교(객체 인스턴스 주소 값)와 동등성 비교(객체 내부의 값) 2가지 방법으로 비교

=>테이블의 로우를 구분하는 방법과 객체를 구분하는 방법에는 차이가 존재

 

이러한 문제점들을 다 해결해 나갈수 있는 기술이 JPA이다. 이러한 방법들을 어떻게 해결햇는지는 JPA를 사용하면서 보여주겠다.