ORM의 탄생 배경(JDBC, Querry Mapper) + 성장 과정

출처 : 내일배움캠프

 

보다 간단하게 정리한 것 : https://cdaosldk.tistory.com/69

1. DB 탄생 후 JAVA 앱과 연동을 위해 JDBC 출시

JDBC Driver Manager는 여러 타입의 DB와 연결할 수 있는 기능을 제공

JDBC Driver Manager는 런타임 할 때 

-Connection을 생성해 쿼리를 요청할 수 있는 상태를 만들고

-Statement를 생성해 쿼리를 요청하게 해주고

-ResultSet을 생성해 쿼리 결과를 받아올 수 있게 한다

사용 후 각각 Close()를 통해 자원을 해제해야 한다

 

JDBC 방식으로 실습해보기

• 연결정보 파라미터 정의
• Connection 생성
• 실행할 SQL 문 지정
• 파라미터 선언과 파라미터 값 제공
• Statement 준비와 실행
• 결과 담기
• Connection, Statement, ResultSet 닫기
• Connection, Statement, ResultSet 예외 처리

-> 중복코드 발생, 예외처리를 DB별로 할 수 없음, 자원 관리를 따로 해줘야한다

2. Querry Mapper : Persistence Framework

SQL Mapper : JDBC Templeate, MyBatis cf) MyBatis : 과거 전자정부 표준

ORM : JPA, Hibernate

 

JDBC Templeate

- 쿼리 수행 결과와 객체 필드 매핑

- RowMapper로 응답 필드 매핑코드 재사용

- Connection, Statement, ResultSet 반복적 처리를 대신 해준다

JDBC Templeate는 JDBC Driver를 추상화하여 동작

MyBatis

-반복적인 JDBC 프로그래밍을 단순화

- SQL 쿼리들을 XML 파일에 작성하여 코드와 SQL을 분리

- 단점 : DB 기능에 종속적, 테이블마다 CRUD 반복, DB 타입 및 테이블에 종속적

 

구현 방법

1. xml

2. 어노테이션 활용 : 쿼리를 어노테이션의 value값으로 넣는 

 

MyBatis 실행 과정 : 

참고 : https://lotuus.tistory.com/75

1. 애플리케이션 시작 시 SqlSessionFactoryBuilder가 설정파일을 참고하여 SqlSessionFactory 생성

2. 애플리케이션에서 DB작업 시 SqlSessionFactory가 SqlSession객체 생성

3. 생성된 SqlSession을 참고해서 mapper인터페이스 호출 (SqlSession에 mapper정보가 내장되어있다)

5. mapper가 SqlSession을 호출하여 SQL실행

3. QuerryMapper의 DB 의존성 및 중복 쿼리 문제로 ORM 탄생

-> ORM은 DAO 또는 Mapper를 통해 조작하는 것이 아니라 테이블을 아예 하나의 객체와 대응 시킨다

4. ORM의 성장 과정

ORM이 해결해야 하는 문제

1) 상속

객체 : 객체 간 멤버변수나 상속관계를 맺을 수 있다

RDB : 테이블들은 상속관계가 없고 모두 독립적으로 존재

해결방법 : 매핑정보에 상속정보를 넣어준다(@OneToMany, @ManyToOne)

 

2) 관계

객체 : 참조를 통해 관계를 가지고 방향을 가진다(다대다 가능)

RDB : 외래 키(FK)를 설정해 Join으로 조회시에만 참조 가능(다대다 관계 시 매핑 테이블 필요)

해결방법 : 매핑정보에 방향정보를 넣어준다(@JoinColumn, @MappedBy)

 

3) 탐색

객체 : 참조를 통해 다른 객체로 순차 탐색이 가능하며 콜렉션도 순회

RDB : 탐색 시 참조하는 만큼 추가 쿼리나, join이 발생하여 비효율적

해결방법 : 매핑/조회 정보로 참조탐색 시점을 관리한다(@FetchType, fetchJoin())

 

4) 밀도

객체 : 멤버 객체 크기가 매우 클 수 있다

RDB : 기본 데이터 타입만 존재

해결방법 : 크기가 큰 멤버 객체는 테이블을 분리하여 상속으로 처리한다(@embedded)

 

5) 식별성

객체 : 객체의 hashCode 또는 정의한 equals() 메소드를 통해 식별

RDB : PK로만 식별

해결방법 : PK를 객체 id로 설정하고 EntityManager는 해당 값으로 객체를 식별하여 관리한다(@Id, @GenerateValue)

 

1차, 2차 캐시

1차 캐시

영속성 컨텍스트 내부에 엔티티를 보관하는 저장소

일반적으로 트랜젝션 시작과 종료 간 1차 캐시가 유효

1차 캐시는 한 트랜젝션 동안 계속 원본 객체를 넘겨준다

 

2차 캐시

애플리케이션 범위 캐시, 공유 캐시, 애플리케이션을 종료할 때까지 캐시 유지

원본 객체가 아니라 복사본을 넘겨준다 ~ 여러 트랜젝션에서 동일한 원본 객체를 수정하지 않도록 하기 위해

적용방법

1. Entity에 @Cacheable 적용 후 설정 추가

2. sharedCache.made 설정

 

영속성 컨텍스트(1차 캐시)를 활용한 쓰기 지연

+ https://cdaosldk.tistory.com/163

JPA 연관관계 매핑 에러 잡기(1)

영속성 : 데이터를 생성한 프로그램이 종료되어도 사라지지 않는 데이터의 특성

~ 파일이나 DB에 저장하며 그 데이터에 부여된다

 

쓰기지연 발생시점

- flush() 동작이 발생하기 전까지 최적화

- flush() 동작으로 전송된 쿼리는 더이상 쿼리 최적화는 되지 않고, 이후 commit()으로 반영만 가능

쓰기지연 효과 ~ 트랜젝션 당 최적화를 통해 최소 쿼리만 날라가게 된다

- 여러 개의 객체를 생성할 경우 그 객체를 모아 한 번에 쿼리 전송

- 영속성 상태의 객체가 생성 및 수정이 여러 번 일어나더라도 해당 트랜젝션 종료 시 쿼리는 1번만 전송

- 영속성 상태에서 객체가 생성되었다 삭제되었다면 실제 DB에는 아무 동작이 전송되지 않을 수 있다

+ 키 생성전략이 .IDENTITY인 경우 생성 쿼리는 쓰기지연이 없다 : 단일 쿼리로 수행하여 외부 트랜젝션에 의한

중복 키 생성을 방지하여 단일 키 보장