JPA (기초 : ORM 의 역사)

이 강의를 바탕으로 정리하였습니다.

자바는 객체 지향 패러다임으로 만들어졌다.

데이터 베이스는 관계형 DB 패러다임으로 만들어졌다.

탄생 배경부터가 다른 패러다임을 두고 만들어졌기 때문에 이 두 소프트웨어는 어쩔 수 없는 간극이 생긴다.

이것은 굉장히 큰 문제다.

1. 프로그래머의 업무는 객체를 CRUD 하는 SQL을 만드는 단순 노동이 된다.

2. SQL에 의존적인 개발을 할 수 밖에 없다.

3. 프로그램을 객체 지향적으로 설계하는데 데이터베이스가 방해된다.

ORM

이러한 패러다임의 불일치를 해결하고자 나온 기술이 ORM (Object Relation Mapping) 프레임워크다.

1. 객체는 객체대로 설계한다.

2. DB는 DB대로 설계한다.

3. ORM은 그 중간을 Mapping 해주는 방식이다.

JPA

ORM 기술은 과거부터 있던 기술이다.

과거의 자바는 EJB의 엔티티 빈이라는 기술을 표준으로 삼았었다.

그러나 알다시피 EJB는 실패했고 사용하기 답답한 엔티티 빈을 대체하기 위해 나온 오픈소스가 Hibernate다.

현재의 자바는 EJB 엔티티 빈의 실패를 인정하고 Hibernate의 개발진을 데려다 거의 똑같이 ORM을 새로 만들었는데 그것이 JPA 이며 현재의 자바 공식 표준이다.

특이한점 : JPA는 설정으로 테이블이 존재하지 않을 경우 테이블을 만드는 DDL도 지원한다.

JPQL

JPA를 사용하면서도 아쉽게도 SQL 쿼리를 어쩔 수 없이 작성해야하는 경우가 생긴다. 

예를 들면 '나이가 15세 이상'을 검색하는 것은 무리다. (JPA의 Read는 완전히 일치하는 경우를 탐색하기 때문이다.)

이럴 경우 대비하여 프로그래머가 SQL문을 제어할 수 있게 해놓았다. 

@NamedQuery(name="", query="") 를 사용하는 경우가 많다.

Spring Data JPA

JPA를 사용한다고해도 기본적인 CRUD는 너무나도 많이 중복됬다.

JPA를 사용해도 반복해서 CRUD 작업을 해야하는 것이 싫어서 나온 기술이 Spring data JPA 이다.

인터페이스 (Repository) 를 만들어서 JpaRepository<엔티티, PK타입>을 상속시키는 방식이다.

간단한 예시

public interface MemberRepository extends JpaRepository<Member, Long>{  List<Member> findByName(String name);  }

특이한 점 : findBy칼럼이름 을 하면 자동으로 이에 해당하는 SQL 쿼리를 생성하고 이 메소드를 구현하는 구현체가 컴파일 타임에 만들어진다.

QueryDSL

SQL을 자바 코드로 작성할 수 있게 도와주는 빌더 API

SQL 문을 직접 작성하는 것이 아닌 자바 코드로 작성한다.

SQL 쿼리의 오류를 컴파일러의 도움을 받아 컴파일 시점에 발견할 수 있다.

검색을 쉽게 할 수 있다.

자바 코드를 사용하기 때문에 코드 재활용이 가능해진다.