[JPA] 1. JPA 소개
SQL 중심적인 개발의 문제점
-
1) 무한 반복, 지루한 코드
- CRUD (Create(Insert Into), Read(Select), Update, Delete)를 반복적으로 설정해야 한다.
- ex) 객체의 새로운 필드값이 생성될 때마다 sql을 매번 재정의
-
2) 패러다임의 불일치
-
객체 vs RDB
- 객체 : 추상화, 캡슐화, 은닉화, 상속, 다형성 등
-
객체 → SQL 변환(개발자) → RDB
-
객체와 RDB 차이
-
상속 : 객체 o, RDB x
- 한 객체를 저장, 조회할 때, 많은 작업을 해야한다. But, 자바 컬렉션(List)을 통해서 한다면? 편하다.
-
연관관계
- 객체 모델링 저장 문제
- 객체 모델링 조회 문제
- 객체 그래프 탐색 문제
-
데이터 타입
-
테이터 식별 방법
-
결국, 진정한 의미의 계층 분할이 어렵다.
JPA 소개
-
JPA : Java Persistence API
-
자바 ORM 표준
- ORM : Object-Relational Mapping
- 객체는 객체대로 RDB는 RDB대로 설계
- ORM이 중간에 매핑
-
애플리케이션과 JDBC 사이 동작
-
저장 & 조회
- 💕(중요)패러다임 불일치 해결
-
JPA 역사?
- EJB(자바 표준 엔티티 빈)
- 문제 : 너무 아마추어(기능, 구현, 성능 ↓)
- 하이버네이트(오픈 소스)
- JPA(자바 표준)
-
JPA는 표준 명세
- JPA는 인터페이스 모음
- 3가지 구현체
- Hibernate(80-90%)
- EclipseLink
- DataNucleus
-
JPA 사용 이유
-
❗SQL 중심 개발 → 객체 중심 개발
-
❗생산성 - JPA와 CRUD
- 저장 :
jpa.persist(member)
- 조회 :
Member member = jpa.find(memberId)
- 수정 :
member.setName("변경 내용")
>> 변경감지
- 삭제 :
jpa.remove(member)
-
❗유지보수
- 기존 : 필드 변경시 모든 sql 수정
- JPA : 필드만 추가하면 sql은 jpa가 처리
-
❗패러다임 불일치 해결
-
1) JPA와 상속
- 저장
jpa.persist(album)
- 조회
Album album = jpa.find(Album.class, albumId);
-
2) JPA와 연관관계
//저장
member.setTeam(team);
jpa.persist(member);
-
3) 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();
}
}
-
4) JPA와 비교
String memberId = "100";
Member member1 = jpa.find(Member.class, memberId);
Member member2 = jpa.find(Member.class, memberId);
//member1 == member2; //같다.
//동일한 트랜잭션에서 조회한 엔티티는 같음을 보장
-
❗성능
-
1) 1차 캐시와 동일성 보장
-
같은 트랜잭션 안에서는 같은 엔티티를 반환
-
DB Isolation Level
이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장
String memberId = "100";
Member m1 = jpa.find(Member.class, memberId); //SQL
Member m2 = jpa.find(Member.class, memberId); //캐시
//println(m1 == m2) //true
//SQL 1번만 실행
-
DB Isolation Level
-
2) 트랜잭션을 지원하는 쓰기 지연
-
INSERT
-
트랜잭션을 커밋할 때까지 INSERT SQL을 모음
-
JDBC BATCH SQL 기능을 사용해서 한번에 SQL을 전송
transaction.begin(); // [트랜잭션] 시작
em.persist(memberA);
em.persist(memberB);
em.persist(memberC);
//여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.
//커밋하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다.
transaction.commit(); // [트랜잭션] 커밋
-
UPDATE
- UPDATE, DELETE로 인한 로우락 시간 최소화
-
3) 지연 로딩과 즉시 로딩
-
지연 로딩 : 객체가 실제 사용될 때 로딩(프록시 객체)
-
즉시 로딩 : JOIN SQL로 한번에 연관된 객체까지 미리 조회
-
❗데이터 접근 추상화와 벤더 독립성
-
❗표준
-
ORM = 객체 + RDB 균형을 잘 맞추기 위해 둘 다 잘해야 한다.
Author And Source
이 문제에 관하여([JPA] 1. JPA 소개), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://velog.io/@jinmin2216/JPA-1.-JPA-소개
저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
1) 무한 반복, 지루한 코드
- CRUD (Create(Insert Into), Read(Select), Update, Delete)를 반복적으로 설정해야 한다.
- ex) 객체의 새로운 필드값이 생성될 때마다 sql을 매번 재정의
2) 패러다임의 불일치
-
객체 vs RDB
- 객체 : 추상화, 캡슐화, 은닉화, 상속, 다형성 등
-
객체 → SQL 변환(개발자) → RDB
-
객체와 RDB 차이
-
상속 : 객체 o, RDB x
- 한 객체를 저장, 조회할 때, 많은 작업을 해야한다. But, 자바 컬렉션(List)을 통해서 한다면? 편하다.
-
연관관계
- 객체 모델링 저장 문제
- 객체 모델링 조회 문제
- 객체 그래프 탐색 문제
-
데이터 타입
-
테이터 식별 방법
-
결국, 진정한 의미의 계층 분할이 어렵다.
-
-
JPA : Java Persistence API
-
자바 ORM 표준
- ORM : Object-Relational Mapping
- 객체는 객체대로 RDB는 RDB대로 설계
- ORM이 중간에 매핑
- ORM : Object-Relational Mapping
-
애플리케이션과 JDBC 사이 동작
-
저장 & 조회
- 💕(중요)패러다임 불일치 해결
-
JPA 역사?
- EJB(자바 표준 엔티티 빈)
- 문제 : 너무 아마추어(기능, 구현, 성능 ↓)
- 하이버네이트(오픈 소스)
- JPA(자바 표준)
- EJB(자바 표준 엔티티 빈)
-
JPA는 표준 명세
- JPA는 인터페이스 모음
- 3가지 구현체
- Hibernate(80-90%)
- EclipseLink
- DataNucleus
-
JPA 사용 이유
-
❗SQL 중심 개발 → 객체 중심 개발
-
❗생산성 - JPA와 CRUD
- 저장 :
jpa.persist(member)
- 조회 :
Member member = jpa.find(memberId)
- 수정 :
member.setName("변경 내용")
>> 변경감지 - 삭제 :
jpa.remove(member)
- 저장 :
-
❗유지보수
- 기존 : 필드 변경시 모든 sql 수정
- JPA : 필드만 추가하면 sql은 jpa가 처리
-
❗패러다임 불일치 해결
-
1) JPA와 상속
- 저장
jpa.persist(album)
- 조회
Album album = jpa.find(Album.class, albumId);
- 저장
-
2) JPA와 연관관계
//저장 member.setTeam(team); jpa.persist(member);
-
3) 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(); } }
-
4) JPA와 비교
String memberId = "100"; Member member1 = jpa.find(Member.class, memberId); Member member2 = jpa.find(Member.class, memberId); //member1 == member2; //같다. //동일한 트랜잭션에서 조회한 엔티티는 같음을 보장
-
-
❗성능
-
1) 1차 캐시와 동일성 보장
-
같은 트랜잭션 안에서는 같은 엔티티를 반환
-
DB Isolation Level
이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장String memberId = "100"; Member m1 = jpa.find(Member.class, memberId); //SQL Member m2 = jpa.find(Member.class, memberId); //캐시 //println(m1 == m2) //true //SQL 1번만 실행
-
DB Isolation Level
-
-
-
2) 트랜잭션을 지원하는 쓰기 지연
-
INSERT
-
트랜잭션을 커밋할 때까지 INSERT SQL을 모음
-
JDBC BATCH SQL 기능을 사용해서 한번에 SQL을 전송
transaction.begin(); // [트랜잭션] 시작 em.persist(memberA); em.persist(memberB); em.persist(memberC); //여기까지 INSERT SQL을 데이터베이스에 보내지 않는다. //커밋하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다. transaction.commit(); // [트랜잭션] 커밋
-
-
UPDATE
- UPDATE, DELETE로 인한 로우락 시간 최소화
-
-
3) 지연 로딩과 즉시 로딩
-
지연 로딩 : 객체가 실제 사용될 때 로딩(프록시 객체)
-
즉시 로딩 : JOIN SQL로 한번에 연관된 객체까지 미리 조회
-
-
-
❗데이터 접근 추상화와 벤더 독립성
-
❗표준
-
-
ORM = 객체 + RDB 균형을 잘 맞추기 위해 둘 다 잘해야 한다.
Author And Source
이 문제에 관하여([JPA] 1. JPA 소개), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@jinmin2216/JPA-1.-JPA-소개저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)