서론
JPA를 사용하지 않으면 데이터베이스와 통신할때 개발자는 직접 SQL 문을 작성해서 개발해야한다.
이 과정에서 패러다임의 불일치가 일어나는데, 근본적인 이유는 객체지향과 관계형 데이터베이스간의 구조 차이이다.
객체와 관계형 데이터베이스의 차이
상속 - DB에 저장할 객체에는 상속 관계를 쓰지 않는다. DB의 슈퍼타입 서브타입 관계를 사용하면 객체의 상속과 유사한 형태로 설계는 할 수 있다. 다만 여기서 개발자가 쓰는 비용이 많아진다. 부모 타입과 자식 타입에 해당하는 테이블을 조인하고 결과 객체를 생성해야 한다.
하지만 데이터가 자바 컬렉션에 보관된다면 타입에 대한 고민 없이 컬렉션을 조회하면 된다.
연관관계 - 객체는 참조를 사용해 다른 객체와 연관관계를 가지는 반면 테이블은 외래 키를 사용해 다른 테이블과 연관관계를 가지고 조인을 사용해 조회한다. 여기서 객체를 테이블에 맞추어 모델링하면 코드상에서 한 쪽 방향밖에 참조를 통한 조회를 할 수 밖에 없다.
객체 그래프 - 객체는 마음껏 객체 그래프를 탐색 할 수 있어야 한다. 하지만 DB에서는 연관 데이터를 조회하지 않으면 탐색할 수 없다. SQL을 직접 작성해서 객체 그래프를 어디까지 탐색할지 정할 수 있지만 이는 객체지향 프로그래밍에서 큰 제약이 된다. 비즈니스 로직에 따라 객체 그래프의 탐색 범위가 다르기 때문이다.
비교 - DB는 기본키값으로 구분하지만, 객체는 동일성과 동등성을 이용해서 비교한다. 따라서 JDBC를 사용하면 서로 다른 인스턴스를 생성하므로 동일성 비교에 실패한다.
결론 : 객체답게 모델링 할수록 매핑 작업만 늘어난다... 여기서 한가지 생각이 든다. '객체를 자바 컬렉션에 저장 하듯이 DB에 저장할 수는 없을까?'
JPA란?
자바 진영의 ORM 기술 표준이다.
ORM
Object-relational mapping(객체 관계 매핑)이며 객체는 객체대로, RDBS는 RDBS대로 설계하는 방식이다. 중간에서 ORM 프레임워크가 매핑해준다.
JPA를 사용해야 하는 이유
- SQL 중심 개발에서 객체 중심 개발 : 매핑작업하다가 비용이 너무 드니 자바 컬렉션처럼 객체 중심으로 개발하면 생산성과 유지보수에 효율적이다.
- 패러다임 불일치 해결 : 기존 JDBC 방식에서의 문제점인 패러다임 불일치 문제를 해결한다. 개발자는 JPA에서 정의한 API대로 코드를 작성하기만 하면 나머지는 JPA가 처리한다.
- 성능 최적화 :
3-1 : 1차 캐시와 동일성 보장 - 같은 트랜잭션 안에서는 같은 엔티티를 반환 >> 조회 성능 향상
3-2 : 트랜잭션을 지원하는 쓰기 지연 - 트랜잭션을 커밋할때까지 INSERT SQL을 모음. 이후 한번에 SQL 전송, UPDATE/DELETE로 인한 로우락 시간 최소화, 커밋시 UPDATE/DELETE SQL 실행하고 바로 커밋한다.
3-3 : 지연로딩 - 객체가 실제 사용될 때 로딩된다. 이와 반대되는 개념은 즉시 로딩인데, 즉시 로딩되면 JOIN SQL로 한번에 연관된 객체까지 미리 조회해서 성능이 떨어진다.
출처 : 인프런 자바 ORM 표준 JPA 프로그래밍 - 기본편
