[JPA] 1. 왜 JPA를 공부해야 할까?

회사에서 MyBatis, iBatis위주로 사용을 해왔는데 요새 JPA라는 기술이 많이 사용되고 있다고 한다.

간단하게 말하면 Java에서 JDBC를 관리해주는 기능인데, 쉽게 관리해주는 기능으로 사용하기가 편리하다고들 한다.

이 기술에 대해 호기심이 생겼고, 현재 진행하고 있는 사이드 프로젝트에 도입할 생각이다.

(실무에서는 어렵다고하기에, 회사 프로젝트는 JPA에 대해 충분히 공부한 후 상황이 적합하다면 도입할 의지가 있다. )

 

그럼, JPA에 대해 알아보자.

 

---

자바 ORM 표준 JPA 프로그래밍

이 포스팅에서 작성하는 내용은 자바 ORM 표준 JPA 프로그래밍 (김영한 지음) 에서 발췌하였습니다.

 

 

1. DB 통신 방식

1-1. JDBC 방식, MyBatis

• 위의 두 방식 모두 개발자가 직접 SQL문을 작성해서 통신을 진행

 

1-2. JPA 방식

• 개발자가 SQL문을 작성할 필요없이 통신을 진행.
• 마치 Java에서 Collection 객체를 사용할 때 자연스레 넣고 가져오듯 사용.
• JPA가 JDBC를 관리하여 적절한 SQL을 생성하고 DB에 요청하는 방식.

 

2. JPA의 수요

2-1. 키워드 'JPA'

대한민국에서의 MyBatis는 우하향 그래프이고, JPA는 우상향 그래프로 JPA에 대한 관심이 점점 많아지는 것을 알 수 있다.

 

이미 전세계는 JPA에 대한 관심이 MyBatis보다 훨씬 높았다는 것을 알 수 있다.

 

2-2. JPA 적용 사례

• 쿠팡, 카카오, 배달의 민족, 네이버 등 국내 유명한 IT 기업에서 사용 중
• 최신 스프링 예제에서도 JPA 이용
• 자바 개발자에게 JPA를 기본 기술이라고 볼 수 있다.

 

3. JPA의 간단한 특징

• 개발 속도와 유지보수 속도가 상당히 빨라짐 → 수 십 줄의 코드를 한두 줄로 작성 가능
• 난이도가 있어 공부해야할 필요가 있음
• 난이도가 있기 때문에 실무에 바로 도입하기엔 어려울 수 있음
  • JPA 관련 예제들은 보통 테이블이 1~2개로 단순한 구조이지만, 실무에서는 수십 개 이상의 복잡한 객체와 테이블을 사용하기 때문.
  • 객체와 테이블을 제대로 설계하고 매핑하는 방법을 완벽하게 숙지한다면 어떠한 복잡한 시스템도 JPA로 설계가 가능

 

4. 최근 기술 동향

4-1. 애플리케이션

애플리케이션에서는 객체 지향 언어를 대부분 사용한다.

* 객체 지향 언어? Java, Scala ...

 

4-2. 데이터베이스

요즈음 NoSQL이 많이 사용되고 있지만, 아직까지는 관계형 DB(RDBMS)가 많이 사용되고 있다.

* NoSQL? MongoDB,Azure Cosmos DB ...

* RDBMS? Oracle, MySQL ...

 

4-3. 애플리케이션과 RDBMS를 같이 사용하면?

애플리케이션이 객체 지향 언어로 사용함에도 불구하고 SQL문이 대부분이다.

→ RDBMS는 SQL만 알아들을 수 있기 때문!!

 

 

5. 기존 방식의 단점

5-1. 단순 노동 작업

• 간단한 테이블을 하나 추가하더라도, CRUD 쿼리를 짜줘야하며 자바 객체를 SQL로 보내주고 또 반대로 SQL에서 자바 객체로 보내주고 하는 단순 노동 작업이 필요하다.
• dto(vo) 객체를 정의 및 이에 알맞게 CRUD쿼리를 작성 후, 특정 컬럼이 추가되는 경우 dto 객체에 해당 컬럼 추가하고~ 작성한 SQL에도 해당 컬럼 추가하는 작업이 필요함.. → 놓치거나 실수할 가능성이 있음

5-2. 패러다임의 불일치

객체 지향 프로그래밍 : 추상화, 캡슐화, 정보은닉, 상속, 다형성 등 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 이용하여 프로그래밍 하는 것을 목표 함.

 

하지만, SQL문을 더 많이 작성하는 경우가 빈번함.

 

* 객체 지향 프로그래밍의 객체 vs RDBMS의 차이

 

1) 상속

RDBMS에는 상속이라는 개념이 없다.

비슷하게 나마, Table 슈퍼타입 서브타입 관계가 있는데 다르다고 볼 수 있다.

 

- Album 데이터를 저장할 때

  객체 : 단순히 Album 객체를 생성하고 저장하면 끝.

  RDBMS : 2번의 INSERT가 필요함 (T.ITEM과 T.ALBUM)

 

- Album 데이터를 조회할 때

  객체 : 컬렉션에서 객체에서 get하면 끝.

  RDBMS : 기본=T.ITEM과 T.ALBUM을 조인하는 SQL문을 작성하여 결과를 받아온 뒤 각각의 객체에 할당...

               하지만 위의 방법은 너무 번거로우므로 DB에서 받아오는 데이터를 저장할 객체에는 상속 관계를 사용X

객체에 Album 데이터를 저장 시, 단순히 Album 객체를 생성하고 할당하면 끝.

 

 

2) 연관관계

- 객체 : 참조를 사용함.

- RDBMS : 테이블간 외래키를 사용하기 때문에 JOIN을 맺어야 함.

 

 

3) 엔티티 신뢰 문제

 - DAO를 호출하여 결과값을 받는 객체를 무조건 신용할 수 없다.

→ 호출하는 쿼리를 확인해야만 함.

 

 

4) 반환된 객체 비교

 

String memberId = "10";

Member member1 = list.get(memberId);
Member member2 = list.get(memberId);
// member1 == member2 (같다)

- 객체 : 컬렉션에서 같은 객체를 A, B에 저장 시 이 두 객체는 같다.

 

 

String memberId = "10";

Member member1 = memberDAO.getMember(memberId);
Member member2 = memberDAO.getMember(memberId);
// member1 != member2 (다르다)

- RDBMS : A라는 쿼리를 보내서 데이터를 받은 1번 객체와 그 이후에 똑같이 A라는 쿼리를 보내서 데이터를 받은 2번 객체와 다름. (안의 내용은 같겠지만 객체가 두 번 생성된 것이므로)

 

 

즉, 위의 두 특징 차이로 인해 객체 지향 언어답게 객체를 모델링할 수록 DB와 매핑 시 번거로워지는 아이러니한 상황이 발생. 

→ 객체를 자바 컬렉션에 저장하듯 DB에 저장하는 기술 : JPA (Java Persistence API)