[JPA] 패러다임 불일치

 

어플리케이션 개발은 주로 객체지향언어로 이루어진다.

 

객체지향언어는 현실의 많은 문제를 코드로 구현 가능하게 하지만  문제가 있다. 데이터는 주로 관계형DB에 저장되는데 관계형DB와 어플리케이션은 패러다임이 다르다. 객체지향언어는 객체를 생성하고 객체간 관계를 맺는다. 반면 관계형DB는 테이블간 외래키로 관계를 맺는다. 객체와 테이블의 개념이 달라, 두 환경의 패러다임 자체가 서로 다르다.  그러므로 중간에 변환과정이 필요하다. 

 

 

JDBC의 등장

 

 

 

Application이 DB에 읽기/쓰기를 하려면 두 환경을 연결할 모듈이 필요하다. 그래서 JAVA언어로 읽기/쓰기를 구현하는 라이브러리가 등장하는데, 그것이 JDBC(Java Database Connectivity)이다.  이후에는 iBatis, MyBatis같은 ORM 기술이 등장하며 JDBC를 조금 더 추상적으로 사용할 수 있게 되었다.

 

그러나 패러다임 불일치 문제는 해결되지 않았다.

쿼리를 사용하는 DB환경의 패러다임은 객체지향환경에 여전히 영향을 끼쳤다.

 

패러다임 불일치

 

객체제향언어는 '상속'의 개념이 있지만 DB환경에는 없다. 

 

 

 

 

Book은 Item을 상속한다.

 

자식객체는 부모객체를 상속하기에, 부모객체가 가지는 멤버변수나 메서드를 사용할 수 있다. Book 클래스에 name 필드가 없어도 부모인 Item 클래스에 name 필드가 있기에, Book 객체는 name 필드를 가진다.  

 

그러나 테이블은 다르다.

 

객체지향에서는 Item이 부모이고 Book이 자식이지만 테이블 관점에서는 그저 두 테이블에 불과하다. Book 클래스에 name 필드가 없으므로 Book 테이블에 name 컬럼이 없다. 책이름을 테이블에 입력하고 싶으면 Item 테이블에 INSERT 해야 한다. 

 

 

 

 

 

 

 

INSERT INTO ITEM ...    (부모)

INSERT INTO BOOK ...  (자식)

 

부모인 ITEM 테이블에 직접 name 데이터를 INSERT해야 한다.

또한 조회시, Item과 Book을 JOIN 연산을 사용하여 데이터를 읽어야 한다. 

 

객체지향에서는 name 필드를 Item 클래스가 가지고 있지만 Item 객체를 신경쓰지 않아도 되었다. Book 객체의 name에 데이터를 입력하고 조회하면 되었다. 이는 객체지향에서 '상속'의 개념이 존재하기 때문에 가능하다.

 

이와 같이  패러다임이 서로 다르다 보니,

조금 더 유연한 객체지향환경이 SQL 중심으로 맞춰주어야 했다. 

 

 

class Item {
    Long id;
    String name;
    String dType;
    Long FK; // 외래키 개념이 자바객체에 사용
}

class Book {
    Long id;
    String author;
    int cost;
}

 

객체지향언어의 환경에서 테이블 개념이 사용된다. 외래키 데이터가 객체지향환경의 필드로 쓰인 것이다.

 

class Item {
    Long id;
    String name;
    String dType;
    Book book; // 주소로 접근
}

class Book {
    Long id;
    String author;
    int cost;
}

 

객체지향환경은 '주소'로 접근하는 '참조' 방식을 사용한다. 참조는 또 다른 참조를 부른다. 그래서 A객체가 D객체를 참조하지 않아도 A ➠ B ➠ C ➠ D로 탐색이 가능하다. 그런데 SQL 중심 프로그래밍을 하다보니 이런 객체지향의 이점을 살리지 못한다. 내가 전에 다니던 회사는 VO를 두 가지로 만들어 운영했다.  객체지향환경의 VO는 SVO, DB와 가까운 VO는 DVO로 구분하였다. 그리고 중간에 SVO를 DVO로 DVO를 SVO로 변환하는 과정을 두었다. 이처럼 패러다임 불일치 문제는 개발자를 두번 생각하게 만들고 코드도 두배로 만든다. 

 

 

JPA가 필요한 이유

 

 

 

 

JPA는 패러다임불일치 문제를 해결한다.

 

과거에는 APP과 DB 사이의 불일치를 개발자가 직접 풀어주었지만 JPA는 Entity Manager, Entity 개념을 사용하여 중간과정을 자동화하였다. SQL중심 프로그래밍에서 객체지향중심 프로그래밍으로 전환된 것이다. 그럼 어떤 원리로 패러다임 불일치가 해결되었는지는 다음 포스팅부터 다루어 보겠다.

 

 

---

 

 

참고자료

 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의