-
Notifications
You must be signed in to change notification settings - Fork 0
JPA 소개 및 탄생 배경
YoungMinKim edited this page Jul 18, 2021
·
1 revision
- SQL 중심적인 개발의 문제점
- JPA 소개
- JPA의 기본적인 이해
- JPA가 탄생한 배경
- `IDE` : Intellij
- `WAS` : Tomcat 9
- `DataBase` : H2
- `Build` : Maven
- JPA란 Java Persistence API의 약자로, 자바 진영의 ORM 표준을 의미합니다.
- JPA와 SQL-Mapper(Mybatis, iBatis)를 비교
- 객체를 중심으로 개발 진행 가능
- 데이터 엔티티의 신뢰성 보장
- 테이블 변경 및 관리에 더욱 더 효과적
- 엔티티의 컬럼을 변경하면 알아서 반영이 된다
- 관계형 RDBMS처럼 테이블 중심이 아닌 객체 중심 개발
객체 중심 개발?: - 기본 CRUD, 페이징 처리, 부가 기능이 미리 제공되어 있다.
- Object-relational mapping(객체 관계 매핑)
- 객체는 객체대로 설계하고 관계형 데이터베이스는 관계형 데이터베이스대로 설계하여,
ORM 프레임워크가 중간에서 매핑해주는 기술
- 대중적인 언어에는 대부분 ORM 기술이 존재
- Mybatis (SQL-MAPPER)
- iBatis (SQL-MAPPER)
- JPA (인터페이스의 집합) - 대표적으로 Hibernate
Java Application => JPA => JDBC API
- JPA는 애플리케이션과 JDBC 사이에서 동작
- 회원 정보를 저장하고 싶다?
- 자바 애플리케이션을 통해 JPA에게 Member 객체 전달
- JPA가 Entity(객체)를 분석
- 적절한 INSERT 쿼리 생성
- JDBC API 사용
- 패러다임 불일치 해결
- 자바 애플리케이션을 통해 JPA에게 Member 객체 전달
- 회원 정보를 조회하고 싶다?
- 자바 애플리케이션을 통해 JPA에게 Member 객체 전달
- 적절한 SELECT SQL 생성
- JDBC API 사용
- ResultSet 매핑
- 패러다임의 불일치 해결
- 자바 애플리케이션을 통해 JPA에게 Member 객체 전달
- 과거에는 EJB - 엔티티 빈(자바 표준)이 존재 하였는데, 기술의 복잡성(속도, 인터페이스 상속 등..) 복잡한 부분이 너무 많이 존재.
- 위 같은 이유로 인해 Open Source ORM Hibernate가 탄생
- Hibernate를 개발한 개발자를 데려와서 JPA(자바 표준)이 탄생
- JPA는 인터페이스의 모음
- JPA 2.1 표준 명세를 구현한 3가지 구현체
- 하이버네이트, EclipseLink, DataNucleus
구현체로 하이버네이트를 대부분 사용한다, 래퍼런스가 활성화 되있음
- SQL 중심 개발에서 객체 중심으로 개발
- 생산성 & 유지보수
- 패러다임 불일치 해결
- 성능
- 데이터 접근 추상화와 벤더 독립성
- 표준(자바 표준)
- 저장(Insert): jpa.persist(member);
- 조회(Select): Member member = jpa.find(memberId);
-
수정(Update): member.setName("변경할 이름");
- 자바 컬렉션에서 데이터를 뺀 후에, 값을 수정하는것을 생각하면 된다
- SQL 개발만 해왔던 필자는 전혀 이해를 할 수 없는 부분.
- 삭제(Delete): jpa.remove(memberId);
- JPA 사용 시 VO의 컬럼만 추가하면 된다.
- 무슨 소리지?
- JPA는 엔티티 및 테이블 관리 변경에 용이하다
- 즉, 자동으로 해당 내용을 수행 해준다
- 무슨 소리지?
- JPA와 상속
- JPA와 연관관계
- JPA와 객체 그래프 탐색
- JPA와 비교하기
//개발자가 할 일 - 저장
jpa.persist(album); //album Entity를 넣어주면 알아서 INSERT
//JPA 처리
INSERT INTO ITEM ...
INSERT INTO ALBUM ...
//개발자가 할 일 - 조회
Album album = jpa.find(Album.class, albumId);
//JPA 처리
SELECT I.*, A.*
FROM ITEM I
JOIN ALBUM A ON I.ITEM_ID = A.ITEM_ID
- 패러다임이 불일치한 부분을 JPA가 처리 해준다.
//연관관계 저장
member.setTeam(team); //Team 객체 삽입
jpa.persist(member); //member 객체를 JPA에 전달
//객체 그래프 탐색
Member member = jpa.find(Member.class, memberId);
Team team = member.getTeam();
// 신뢰할 수 있는 인티티, 계층
class MemberService {
...
public void process() {
Member member = memberDao.find(memberId);
member.getTeam(); //자유로운 객체 그래프 탐색
member.getOrder().getDelivery();
}
}
- persist를 통해 DB에 데이터 삽입
-
member.getTeam() 컬렉션에서 데이터를 꺼내오듯이 객체를 받을 수 있다?
- 이유는 뒤에서 설명을 하겠지만, 영속성 컨텍스트라는 특징이 있기에 가능
-
쿼리에 종속적이지 않기 때문에 객체 그래프를 자유롭게 탐색할 수있다.
- 엔티티의 신뢰성 보장
String memberId = "100";
Member member1 = jpa.find(Member.class, memberId);
Member member2 = jpa.find(Member.class, memberId);
member1 == member2 //같다
- (중요) JPA는 동일한 트랜잭션에서 조회한 엔티티는 같음을 보장해준다.
- SQL의 경우 조회한 엔티티가 같지 않은것으로 나왔다.
- 1차 캐시와 동일성(identity) 보장
- 트랜잭션을 지원하는 쓰기 지연(transaction write-behind)
- 지연 로딩(Lazy Loading)
- 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상
- DB Isolation Level이 Read Commit이여도 애플리케이션에서 Repeatable Read 보장
String memberId = "100";
Member member1 = jpa.find(Member.class, memberId); //SQL 날리고
Member member2 = jpa.find(Member.class, memberId); //캐시에서 가져옴
println(m1==m2); //true
- 위 예시를 보면 jpa.find를 두번 날리고 있다
- SQL의 경우에는 두번 쿼리가 날라가겠지만, JPA는 캐시를 통해 쿼리가 한번 날라간다.
- 실제 실무에서 큰 도움이 안된다고 하는데, 왜 많은 도움이 안될까?
- ex) 비즈니스 로직이 복잡하여 맴버를 무차별적으로 많이 조회를 한다.
- 트랜잭션을 커밋할 때까지 INSERT SQL을 모아둔다
- JDBC BATCH SQL 기능을 사용해서 한 번에 SQL 전송
transaction.begin();
em.persist(memberA);
em.persist(memberB);
em.persist(memberC);
//commit하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다.
transaction.commit(); //[트랜잭션 커밋] -> 이 때 날라간다
- 하나의 트랜잭션 단위 내에서, commit을 통해 SQL을 관리할 수 있다.
- 비슷한 쿼리가 들어가야 하는 상황
- 한 번에 들어가든, 한 번에 모아서 들어가든 결과는 똑같음
- UPDATE, DELETE로 인한 로우(ROW)락 시간 최소화
- 트랜잭션 커밋 시 UPDATE, DELETE SQL 실행하고 바로 커밋
tansaction.begin(); //[트랜잭션] 시작
changeMember(memberA);
deleteMember(memberB);
비즈니스_로직_수행(); //비즈니스 로직 수행 동안 DB 로우 락이 걸리지 않는다.
//커밋하는 순간 데이터베이스에 UPDATE, DELETE SQL을 보낸다
transaction.commit(); //[트랜잭션] 커밋
//지연로딩
Member member = memberDao.find(memberId);
Team team = member.getTeam();
String teamName = team.getName();
1. SELECT * FROM MEMBER //먼저 실행
2. SELECT * FROM TEAM //team값이 실제 필요할 경우 해당 쿼리 실행
//즉시로딩
Member member = memberDao.find(memberId);
Team team = member.getTeam();
String teamName = team.getName();
SELECT M.*, T.*
FROM MEMBER JOIN TEAM ....
-
지연 로딩: 객체가 실제 사용될 때 로딩
- 지연 로딩은 쿼리가 두번 날라간다는 단점이 있다
-
즉시로딩 : JOIN SQL로 한 번에 연관된 객체까지 미리 조회
- JPA 옵션을 설정 후 즉시 로딩 설정 가능
- Member랑 Team 조회 시 한 번에 가져오도록 설정 가능
- ORM은 객체와 RDB 두 기능위에 있는 기술