1. JPA 배경
JPA(Jakarta Persistence API)가 나타난 배경은 자바 기반의 애플리케이션 개발에서 객체-관계 매핑을 처리하는 과정에서 발생하는 문제들을 해결하고자 함에 있다.
기존에는 RDBS와 상호작용하기 위해 JDBC(Java Database Connectivity)를 사용했다.
하지만, JDBC를 사용하는 과정에서 생기는 문제가 있었다.
1. 반복적인 코드 : 직접 SQL 쿼리(CRUD)를 작성하며 객체-관계 매핑
2. 패러다임의 불일치 : 객체와 관계형 DB의 차이 -> 객체에서 필드 수정 시 SQL도 수정 필요
DB 패러다임의 불일치란?
객체 지향 프로그래밍
추상화, 캡슐화, 정보은닉, 상속, 다형성 등 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 제공한다.
필드와 메서드 등을 묶어서 잘 캡슐화해서 사용하는 것이 목표
관계형 데이터베이스 (RDB)
데이터를 잘 정규화해서 보관하는 것이 목표
패러다임이 다른 두 가지를 가지고 억지로 매핑하기 때문에 여러 가지 문제가 발생한다.
Object를 RDB에 넣으려고 하니까 문제가 발생한다.
3. 객체(Object)와 관계형 데이터베이스(RDB)의 차이
객체 | RDB | |
상속 | 상속 관계 O | 상속 관계 X 유사한 물리모델로, Table 슈퍼타입 서브타입 관계 존대 |
연관 관계 | 참조를 사용하여 연관관계 단방향으로만 관계 존재 |
외래키(FK)와 join쿼리를 통해 연관관계 |
중요한 데이터를 RDB에 저장해야 하므로 이러한 차이들을 SQL에 의존하여 개발을 할 수밖에 없고,
개발 생산성 저하, 복잡한 코드, 유지 보수의 어려움 등의 문제가 발생했다.
그렇기에 객체-관계 매핑을 자동화하고, 객체 지향 프로그래밍의 장점을 활용할 수 있는
ORM(객체-관계 매핑) 기술이 필요해졌고, 이를 위한 표준 스펙인 JPA가 등장하게 되었다.
2. JPA 란
- 자바 진영의 ORM 표준
- Java 애플리케이션과 JDBC API 사이에서 동작
- JPA는 ORM 기술 표준으로 인터페이스의 모음 구현체는 Hibernate, EclipseLinke, DataNucleus가 있음.
- 구현된 클래스와 매핑을 해주기 위해 사용되는 프레임 워크 (실질적 구현 X)
개발자가 객체를 데이터베이스에 영속화(저장)하고, 데이터베이스의 데이터를 객체로 변환하는 작업을 자동으로 처리하여 개발 생산성을 향상한다
이는 객체 지향적인 방식으로 데이터베이스와 상호작용할 수 있도록 도와주는 기술이다.
3. JPA 사용 이유
SQL 중심적인 개발에서 객체중심적인 개발이 가능하다.
생산성 증가
- DDL문 자동 생성
- 간단한 메서드로 CRUD가 가능해진다.
- 저장: persist()
- 조회: find()
- 수정: setName()
- 삭제: remove()
- SQL을 작성하고 JDBC API를 사용하는 반복적인 일을 대신 처리해 준다.
유지보수성 향상
- 기존 : 필드 변경 시 모든 SQL 수정
- JPA : 필드만 추가하면 된다. SQL은 JPA 가 처리한다.
- 엔티티(Entity)라는 개념을 통해 데이터베이스 스키마와 애플리케이션의 객체 모델을 연결
Object와 RDB 간의 패러다임 불일치 해결
- 객체 상속 시 SQL은 JPA가 알아서 처리하므로 고려 X
- 연관 관계 저장 가능 및 객체 그래프 탐색 지원
- 동일 트랜잭션에서 조회한 엔티티는 같음을 보장
성능 최적화
- 영속성 컨텍스트(Persistence Context)라는 메모리 내의 객체 저장소를 제공
- 1차 캐시와 동일성 보장
- 트랜잭션을 지원하는 쓰기 지연
- 지연 로딩, Lazy Loading
- 캐시, 배치 처리
4. JPA 작동 방식
JPA는 애플리케이션과 JDBC 사이에서 동작한다.
- MemberDAO 클래스를 통해 find(id)를 호출하면, JPA는 SELECT SQL을 생성한다.
- JDBC API를 사용하여 생성된 SELECT SQL을 DBFH 보낸다.
- DB에서 반환된 정보를 ResultSet 매핑을 통해 Entity 객체로 변환해 준다.
- 이 과정에서 패러다임 불일치 문제를 해결해 준다
5. JPA 장단점
• 장점
- SQL문이 아닌 메서드를 통해서 DB 조작이 가능하기 때문에, 개발자는 객체 모델을 이용하여 비즈니스 로직을
구성하는데만 집중이 가능해진다.
- 객체지향적인 코드 작성이 가능해진다.
- 유지보수 및 리팩토링에 유리하다.
• 단점
- 프로젝트의 규모가 크고 복잡하여 설계가 잘못된 경우에는 속도 저하 및 일관성을 무너뜨리는 문제점이
발생할 수도 있다. ( 개발자가 의도하지 않은 자동으로 생성된 Query로 인해 성능이 저하되기도 함 )
- 복잡한 동적 Query문같이 속도를 위해 별도의 튜닝이 필요하기 때문에 결국 SQL문을 쓰는 게 나은
상황이 발생할 수도 있다.
- 학습비용이 비싸고 시간이 오래 걸린다.
'Back-End > Spring' 카테고리의 다른 글
[JPA] Entity를 Dto로 변환(리턴)의 중요성 (0) | 2023.05.08 |
---|---|
[JPA] 도메인 설계, 엔티티 매핑 (0) | 2023.04.19 |
[Spring] 테스트 코드 작성, Mock (0) | 2023.04.17 |
[MVC-2편] 오류 코드와 메시지 처리 (0) | 2023.04.16 |
[MVC-1편] 웹페이지, 타임리프(Thymeleaf) 구성 (0) | 2023.03.22 |