[JPA] JPA에 대해서

무언가 개발을 하려고 열심히 만들고 보면 DB에 접근해서 데이터를 저장을 하던 조회를 하던 수정,삭제를 하던간에 SQL이 필수적으로 들어 가야한다.

SQL 쿼리를 개발자가 하는게 나쁘다는건 저~~얼~~때 아니다 개발자가 쿼리를 알아야 DB를 사용할 것 아닌가 ~?

다만.....

유저에 대한 기능을 위한 CRUD 상품을 위한 CRUD 상품 상세를 위한 CRUD... 

JPA를 사용하기전에 이러한 의문점을 한번 가져보자

왜 계속해서 반복적인 CRUD가 들어가야할까 ~? 그렇다면 계속해서 새로운 기능이 추가될 때 마다 지루한 CRUD 작업을 추가해야 하는건가 ??

 

여태 내가 개발해왔던 방식은 "SQL 중심적 개발" 이였다.

이러한 SQL 중심적 개발 방식을 사용하다보면 개발자는 어느덧 SQL 매퍼 역활을 하고있으며 프로젝트는 객체지향 적 설계랑은 좀 멀어지게된다.

 

SQL 중심적 개발의 문제점

• 필드가 추가되면 CRUD 관련한 SQL 작업을 모두 수정해야 한다.
• 데이터를 핸들링(CRUD) 하기위해 SQL에 의존적인 개발을 해야한다.
• 개발자는 SQL 매퍼의 역활을 하게된다 ...
      *SQL 매퍼 : 조회 하더라도 SQL로 들고온 데이터를 객체에 매핑하던지 INSERT를 위해 객체를 SQL로 매핑하는것

---

객체관계 관점 과 관계형 DB 관점

"객체관계" 관점 과 "관계형 DB" 관점을 아래 5가지 항목으로 비교해보았다.

 

1. 객체관계 와 RDB 차이

• 객체는 상하관계가 있지만 RDB는 상하관계를 표현하기가 어렵다
  (SuperType-SubType 이 있긴하나 테이블을 부모뿐 아니라  자식수만큼 만들어야함)
• DB에서 상하관계로 데이터를 가져온다 치면 부모-자식을 Join하여 가져와야하고 데이터를 insert 하더라도 부모와 
  자식 각각 테이블에 데이터를 넣어야한다.
• 상하관계를 가진 객체관계에서는 부모타입의 컬렉션에 자식타입 객체 한번만 넣으면 끝나며 가져올때 해당 컬렉션에서 자식타입의 key값으로 자식타입이나 부모타입으로 객체를 가져올 수 있다.

 

2. 테이블에 맞춘 객체모델링 과 객체다운 모델링

• 테이블은 보통 관계를 맺을때 FK를 가지고 맺게 된다 그렇기 때문에 클래스를 설계할때 FK를 나타내기위해 테이블에 있는 FK(보통 시퀀스값 , teamId(integer))를 나타내는 필드를 가지고 있게된다.(객체답지 못함)
• 객체관계를 참조로 연관관계를 맺기때문에 클래스 설계시 참조타입 필드를 가지게 된다.

 

3. 객체다운 모델링을 그대로 쓰면서 SQL 매퍼역활도 그대로하게되면?

• Insert만 하더라도 참조필드를 테이블에 FK에 그대로 매핑할 수 없기에 무언가 추가작업이 있어야한다
  (team.getId 같은..)
• 조회시 연관관계 테이블을 join하여 가져와서 매핑을 해줘야하는데 그럼 연관관계 데이터를 가져온 다른객체를 통해 연관관계 객체들을 만들고 매핑하고 관계를 맺어줘야한다..
  (vo -> new Member(vo) , new Team(vo) -> member.setTeam(team)) -> 추가 작업이 너무 많아진다는 문제점

 

4. 탐색범위의 차이

• RDB는 조회해온 SQL 범위에 따라서 탐색범위가 결정된다(member와 team만 join 했다면 order는 볼 수가 없다) 
  자유롭게 탐색하려면 모든 경우의수를 다 sql 쿼리로 만들어놔야한다..
• 객체는 연관관계가 이미 다 맺어져 있다라고 RDB와 동일한 상태라고 보면 탐색범위가 자유롭다(team.getMember().getOrder().getOrderItem()...)

 

5. 객체 비교

• SQL을 통해 매퍼로 가져오게된 객체는 동일 SQL을 통해 가져오더라도 다른객체이다.
  컬렉션에서 동일 키값으로 객체를 두번꺼내오면 두 객체는 동일 객체이다(obj1==obj2) 
  단, JPA에서는 동일 트랜젝션 안에서 조회한 엔티티는 동일함을 보장한다.

 

 

결론적으로 SQL 중심적 개발 방식으로는 객체지향적 설계가 불가능하다 그리고 객체관점 과 관계형 데이터베이스의 관점이 서로 다르기에 패러다임의 불일치가 일어난다.
그래서 객체를 자바 컬렉션에 저장하듯 DB에 저장할 수없을까 생각하여 나온 방식이 JPA(Java Persistence API) 이다.

---

JPA란?

• 자바진영 ORM 표준 기술
  *ORM (Object Relation Mapping) : 객체는 객체답게 , 관계형 DB는 DB에 맞게 설계하여 중간에서 매핑 해주는것
• 개빈 킹 이라는 개발자가 만든 "하이버네이트" 라는 ORM 오픈소스 기반으로 만들게됌
  (탄생은 구현체인 hibernate가 먼저 나왔지만 나중에는 오히려 JPA에 맞춰서 hibernate를 컨버팅하게 되었다고 한다.)
• JPA는 표준명세로 그냥 인터페이스의 모음이다.
• JPA를 구현하는 구현체는 Hibernate , EclipseLink , DataNucleus가 있다.

 

JPA 사용이유

• SQL 중심적 개발방식이 아닌 객체 중심방식으로 개발이 가능해진다.
• 생산성 측면에서 훨씬빠르다(지루한 SQL 작업이 없어지기에)
• 유지보수에도 용이하다
  (SQL 중심적일때는 추가 컬럼이 생겼을때 CRUD 쿼리 모두 변경해야 했지만 JPA를 사용할때는 엔티티만 수정)
• 상속,연관관계,객체그래프 탐색,동일 객체 비교 등 RDB와 객체세상의 패러다임(개념 또는 틀) 불일치를 해결해준다.

 

 

블로그를 근 2년만에 다시 써보는것 같다 

최근에 이직한 회사에서 JPA를 사용할 것 같아 리마인드 차원에서 JPA 관련 주제로 블로그에 기록을 할까 한다.

한번 잘 지켜보자 !!!.....