JPA 소개

• 기존에 존재하던 DB 핸들링 기법
  • JDBC API를 직접 사용하기
  • SQL Mapper(JDBC Template, MyBatis) 사용하기

기존의 방법들은 객체지향적 모델링에 맞지 않고 SQL(데이터) 중심의 코드를 구현하게 함
객체와 관계형 데이터베이스 간의 차이를 중간에서 해결해주는 ORM(Object Relation Mapping) 프레임워크가 존재, JPA는 ORM의 자바 표준
기존의 반복되는 CRUD SQL과 객체지향 데이터 모델링과 관계형 데이터베이스 간 차이점을 해결

기존 SQL(데이터) 모델링 중심의 문제점

• SQL 중심의 의존관계가 형성
• 엔티티(비즈니스 모델)을 신뢰할 수 없음
  엔티티를 신뢰할 수 없어 DAO와 SQL을 확인 해봐야 함
• 계층의 분할이 아닌 계층 숨김이 되어 있음
  SQL Mapper를 이용하면 계층 숨김인거지 계층 분할이 아님

JPA를 사용해야 하는 이유

패러다임 불일치

• 상속과 연관 관계

  • 상속
    객체 관계에서는 단순히 컬렉션을 사용하여 상속 관계에 대한 객체를 사용 가능
    DB모델링에서는 객체를 분해, 각 SQL을 생성하여 만들어야 함

  • 연관
    객체는 각 객체에 대한 참조를 유지, 참조를 통해 연관 객체를 사용
    DB 모델링에서는 테이블 외래 키를 사용, Join을 통해 연관 테이블을 조회
    이 두 가지의 접근 방법은 너무너무너무 간격이 커서 객체지향 모델링보다는 DB 모델링에 프로그램이 종속되게 만들었음.

  • 연관 관계 상 문제점
    객체의 경우 참조에 대한 접근 즉 a -> b는 가능하지만 b -> a는 불가능 함
    하지만 DB 모델링의 경우 외래키만 존재한다면 양 테이블 접근 가능

  • 객체지향 모델링 상 문제점
    객체지향 모델링은 참조를 통해 접근, DB는 테이블 외래키를 통해 접근
    객체는 참조가 필요하지만 테이블은 참조가 필요없고 외래키만 필요하니 개발자가 중간에 변환을 해야 한다.

• 객체 그래프 탐색
  

  • 객체는 자유롭게 그래프를 탐색 가능 각 상속, 연관 관계만 맺어져 있다면
    멤버 -> 오더 -> 오더아이템 -> 아이템 -> 카테고리까지 접근 가능
  • 하지만 DB의 경우 미리 그래프의 범위를 정해주어야 하고, 정해진 그래프 범위로 넘어갈 수 없으며 데이터가 없으면 탐색할 수 없다

• 비교
  DB의 경우 row(행)으로 데이터를 구분하는데, 이 데이터들은 서로 동일하지 않다.
  같은 row를 조회 하더라도 == 연산자를 통해 비교시 객체 관점에서는 서로 다른 인스턴스가 된다.

JPA란 무엇인가?

JPA

• JDBC 위 구현된 계층으로 ORM을 자바 표준으로 구현
• 자바코드->JDBC 간 패러다임의 불일치를 자바코드->JPA->JDBC를 통해 해결
• 개발자 입장에서는 객체지향 모델링에 따른 프로그래밍 후, JPA가 객체와 SQL을 어떻게 매핑 해야할지만 알려주면 해결

그래서 JPA를 왜 써야 하는데?

• 생산성 향상
  SQL을 직접 작성하지 않아도 됨
• 유지보수
  SQL을 관리하지 않아도 됨
• 패러다임 불일치 해결
  JPA가 하나의 추상 계층 역할을 해주므로 JPA만 관리하면 됨
• 트랜잭션 비용 감소
  N+1 문제 등을 해결 할 수 있음
• 추상화와 벤더 독립성
  JPA라는 새로운 추상계층을 통해 Persistent Layer를 관리하므로 각 DB에 종속될 필요가 없음
  MySQL, Oracle, H2 DB 등 모든 DB는 추상 계층을 통해 우리에게 보여짐

정리

• JPA는 ORM의 자바 표준, Hibernate는 그 구현체인 프레임워크
• 실제 객체지향 모델링과 데이터 관계 모델링은 패러다임의 불일치가 있음
  • 상속과 연관
  • 그래프 탐색
  • 비교
• JPA는 또 하나의 추상계층으로 개발자가 객체지향 모델링에 집중할 수 있게함

궁금증

• JPA라는 추상 계층이 하나 더 생기는 것도 그것으로 인한 트랜잭션 비용은 별로 안드나? 오히려 트랜잭션 비용이 감소 한다는게 신기함