더 이상 물러설 곳이 없다

상속은 객체지향 프로그래밍에서 굉장히 중요하다.

하지만 관계형 데이터베이스에는 상속 개념이 존재하지 않는다

RDB에는 상속 개념과 매우 유사한 슈퍼-서브 타입이라는 관계 개념이 존재하는데, JPA가 패러다임의 불일치 해소라는 그 목적성에 맞게 객체지향의 상속을 RDB의 슈퍼-서브 타입으로 잘 매핑해준다.

RDB에서 슈퍼-서브 타입을 표현하는 방식은 세 가지가 있는데 JPA는 이 방법을 모두 지원한다.

1. 조인 전략 (가장 많이 사용됨)

가장 바람직한(?) 모델로 평가받는 조인을 이용한 방식이다.

조인 전략이 구조적으로도 객체지향의 상속을 가장 잘 나타내지 않나 싶다.

부모 클래스의 테이블이 공통속성을 가지고 자식 테이블들은 각자의 고유한 컬럼들을 따로 갖는다.

부모의 PK를 자식의 PK이자 FK로 사용했는데, JAVA에서 자식 객체를 검색할 경우 이를 통해 조인 쿼리를 날려서 찾아낸다. 

테이블이 정규화 되어있기 때문에 효율적인 구조라 할 수 있으며 쓸 데 없이 낭비되는 저장공간이 없다는 장점이 있다.

단점으로는 조회할 때 조인 사용량이 높아 성능이 저하될 수 있다는 부분, 새로운 데이터 저장 시 부모, 자식 테이블에 따로따로 insert문을 날려야 한다는 점이 있다.

@Entity
@Inheritance(strategy = InheritanceType.JOINED)  // 상속 매핑 전략 선택
@DiscriminatorColumn  // 자식 객체를 구분하기 위한 Dtype
public abstract class Item {
    // 부모 테이블은 공통된 속성에 대한 컬럼만을 갖는다
    @Id @GeneratedValue
    private Long id;

    private String name;
    private int price;
}

2. 단일 테이블 전략 (디폴트)

테이블 하나에다 모든 자식의 정보를 때려넣는 방식이다.

상속 매핑 전략을 따로 설정하지 않으면 이 방식이 기본으로 적용된다.

(다른 자식의 속성 컬럼에 대해선 NULL을 갖는다)

Dtype 컬럼의 존재가 필수적이다. 조인 전략에서는 굳이 Dtype이 없어도 조인을 통해 알아낼 수는 있지만 단일 테이블 전략에서는 Dtype이 없으면 객체를 구분할 수가 없다.

이러한 이유로 @DiscriminatorColumn을 넣지 않아도 자동적으로 Dtype 컬럼이 추가된다.

하나의 테이블에 모든 정보가 다 담겨있기 떄문에 조인 없이 바로 select가 가능하여 조회 성능이 빠르다는 장점이 있다.

단점으로는 다른 자식들에 대한 고유 속성 컬럼은 NULL값으로 가지고 있어야하므로 자식 엔티티의 컬럼들은 전부 다 NULL이 허용되며, 테이블이 너무 커져버릴 수 있다는 점이 있다.

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)  // 전략 선택 안 하면 디폴트로 싱글 테이블 적용
@DiscriminatorColumn  // 자식 객체를 구분하기 위한 Dtype (싱글 테이블에선 명시하지 않아도 자동 생성됨)
public abstract class Item {

    @Id @GeneratedValue
    private Long id;

    private String name;
    private int price;
}

3. 테이블 퍼 클래스 전략 (사용하지 말 것!)

부모 클래스에 대한 테이블은 존재하지 않는다.

각 자식 클래스 별로 자신만의 테이블을 갖는데, 이때 부모가 갖고 있어야 할 고유한 속성들을 모든 자식 클래스가 자신의 테이블에 갖고 있는 방식이다.

서브 타입(자식)에 대한 구분이 명확하다는 것과 싱글 테이블 전략과는 다르게 NOT NULL 조건을 사용할 수 있다는 장점이 있다.

단점으로는 하나의 부모에 자식이 여럿일 경우 조회 성능이 굉장히 느려지게 된다는 점이 있다.

각각의 자식 테이블 중에 찾고자 하는 객체가 어느 곳에 있는지 알 수 없기 때문에 모든 테이블을 검사해야 한다.

이를 위해서 UNION 을 사용해 모든 테이블을 합치고 그것을 조회한다.

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)  // 웬만하면 사용을 자제해야 하는 전략
@DiscriminatorColumn  // 자식 객체를 구분하기 위한 Dtype
public abstract class Item {

    @Id @GeneratedValue
    private Long id;

    private String name;
    private int price;
}

위 세 가지 방법 모두 부모 클래스는 abstract로 생성해야 한다.

그렇지 않으면 JPA가 부모 클래스의 개별 테이블까지 함께 만들어버린다.

(Item 클래스는 공통 속성을 한 번에 관리하기 위함일 뿐, Item에 대한 개별 테이블은 필요 없다)

다대다 관계의 경우 그대로 사용하지 못하고 반드시 정규화를 통해 중간 테이블을 만들어줘야 한다.

이러한 관계가 있을 때 반드시 중간 중간 테이블을 두어 일대다+다대일 형태로 변형해줘야 한다.

JPA에서는 @ManyToMany를 통해 연관관계를 매핑할 경우 하이버네이트가 위와 같은 중간 테이블을 알아서 만들어서 처리해준다.

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @Column(name = "USERNAME")
    private String username;

    @ManyToMany
    @JoinTable(name = "새로 만들어줄 중간 테이블 이름")
    private List<Product> products = new ArrayList<>();
}
.
.
.
@Entity
public class Product {

    @Id @GeneratedValue
    private Long id;

    private String name;

    @ManyToMany(mappedBy = "products")
    private List<Member> members = new ArrayList<>();
}

위와 같이 @ManyToMany로 양방향 매핑 되어있을 때 (굳이 양방향이어야 할 필요는 없음. 단방향이어도 괜찮다) Member의 @JoinTable(name = "새로운 테이블 명")을 통해 중간 테이블을 따로 만들어준다.

하지만 이러한 방식은 실무에서 절대로 사용하면 안 된다.

중간테이블을 만들고 PK, FK 쌍을 알아서 매핑해주는 것 까지는 문제가 없는데, 실무 레벨에서는 이러한 테이블 매핑에 필요한 필수적인 정보들 외에도 중간 테이블이 가져야하는 여러 가지 컬럼들이 있을 수 있다.

(예를들어 멤버 - 오더 - 상품 이렇게 되어있을 경우 오더가 발생한 시간이라든가 하는 정보들)

하이버네이트에 의해 생성된 중간 테이블은 관계 설정에 필수적으로 필요한 정보들만 담겨있을 뿐 이러한 비즈니스 로직상 필요한 정보들은 담기지 않는다.

따라서, 실무 단계에서는 @ManyToMany는 절대 사용하지 말아야 한다.

다대다 관계를 사용하고 싶은 경우라면 중간 테이블에 대한 클래스를 직접 만들어서 @ManyToOne과 @OneToMany의 조합을 만들어 사용해야 한다.

중간 테이블을 직접 만들어서 관계를 매핑하면 아래와 같은 형태가 된다.

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @Column(name = "USERNAME")
    private String username;

    @OneToMany(mappedBy = "member")
    private List<MemberProduct> memberProducts = new ArrayList<>();
}
.
.
.
@Entity
public class Product {

    @Id @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "product")
    private List<MemberProduct> memberProducts = new ArrayList<>();
}
.
.
.
@Entity
public class MemberProduct {

    @Id @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;

    @ManyToOne
    @JoinColumn(name = "PRODUCT_ID")
    private Product product;
}

Member(ONE) - (MANY)MemberProduct(MANY) - (ONE)Product

MemberProduct는 Order 정도의 역할이 되겠다.

중간 테이블을 하나의 엔티티 개념으로 사용하면 (MemberProduct -> Order) 이러한 형태를 가질 수 있게 된다.

(ORDER_ID는 Generated Value로 주어진 비즈니스적 의미를 갖지 않는 값)

이전에 말했듯이 JPA는 객체와 DB의 패러다임 불일치로 인한 불편을 없애고 객체를 마치 Collections에 저장하는 것처럼 DB에 저장할 수 있게 하기 위해서 등장했다.

개발을 하다보면 필연적으로 연관관계를 가진 테이블들이 존재할 수밖에 없게 되는데 이에 대해선 어떻게 처리해야 할까?

N : 1의 관계로 이루어진 Member와 Team이 있다고 하자. 하나의 Team에 여러 Member가 소속될 수 있고 이러한 관계를 나타내기 위해 Member가 Team의 PK를 FK로 가지게 될 것이다. 

이러한 방식을 따라 클래스를 설계하면 아래와 같은 형태가 된다.

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @Column(name = "USERNAME")
    private String name;

    @Column(name = "TEAM_ID")
    private Long teamId;
}

그런데 이는 DB에 종속적으로 맞춘 설계이다. 즉, 객체 지향적인 설계라고 볼 수 없다.

위와 같이 설계를 한다면 em.find(memberId) 로 member를 찾고, member.getTeamId()를 통해 teamId를 찾고 다시 그걸 이용해 em.find(teamId)로 해당 멤버가 속한 팀을 찾아야 한다.

하지만 여태껏 자바 프로그래밍을 해왔던 대로라면 Member 안에 Team 객체에 대한 변수를 두어 참조 관계를 형성하고 member에서 바로 Team 객체에 접근하도록 하는 것이 우리가 지금까지 해왔던 객체지향적인 설계이다.

앞서 언급했다시피 JPA는 이러한 패러다임 불일치를 없애고 객체 지향적인 설계에 집중할 수 있도록 도와주는 도구이다.

아래와 같은 방법으로 객체 지향적인 모델링을 할 수 있다.

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @Column(name = "USERNAME")
    private String name;

    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
}

참조 관계처럼 Member가 Team team을 직접 소유한다. 그리고 @ManyToOne을 통해 Member : Team의 N : 1 관계를 표현한 후 @JoinColumn을 통해 DB 내에서 Member 테이블이 FK로 가질 Team 테이블의 PK를 지정해준다.

위와 같은 방식의 연관관계 매핑을 '단방향 연관관계'라고 한다. Member는 참조 변수 team을 통해 자신이 속한 Team에 접근이 가능하지만 Team에선 자신에게 속한 Member들에 접근이 불가하기 때문에 단방향이라는 이름이 붙었다.

그런데 일반적인 관계형 데이터베이스에서는 항상 양방향 연관관계를 지원한다. 조인된 테이블을 조회할 때를 생각해보자면.. Member는 자신이 FK로 teamId를 사용해 Team을 조회할 수 있고, Team은 자신의 PK를 FK로 가진 Member들을 검색하는 방식으로 자신에 속한 Member들에 접근이 가능하다.

이러한 양방향 연관관계는 아래와 같이 표현할 수 있다.

@Entity
public class Team {

    @Id @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    private String name;

    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();
}

Member의 List를 참조변수로 둠으로써 양방향 연관관계를 나타냈다.

(이때 new ArrayList<>()로 굳이 초기화를 해준 이유는 관례 상 대부분 그렇게 하기 때문)

주의할 것은, 이번에는 Member가 아닌 Team 기준이기 때문에 @ManyToOne이 아니라 @OneToMany를 사용해야 한다는 것이다. 이때 속성으로 주어진 mappedBy에는 Member에서 자신을 참조하고 있는 참조변수의 이름을 넣어주는 것이다. (Team team)

사실 위와 같은 경우를 편의상 양방향 연관관계라고 말하기는 하지만 진정한 양방향 연관관계라고 볼 수는 없다.

단방향 연관관계 두개를 두어 양방향 연관관계처럼 사용하도록 한 것이다.

그런데 여기까지 왔다면 몇 가지 의문점이 생긴다.

1. 왜 Member에서는 @JoinColumn(name = "TEAM_ID")로 관계를 표현하고 Team에서는 @OneToMany(mappedBy = "team")관계를 표현하는가?  (물론 Member에도 @ManyToOne이 있긴 하지만)

2. 두 테이블을 잇는 TEAM_ID라는 컬럼은 Member, Team 중 어느 쪽에서 관리해야 하는가?

위와 같은 문제는 양방향 연관관계에서 항상 발생하게 되는데 이것을 이해하기 위해 "연관관계의 주인(Owner)" 이라는 것을 정해야 한다. 양방향 관계를 완성하는 두 개의 단방향 관계 중 하나의 관계를 주인으로 지정하는 것이다.

일반적으로 FK를 가진 곳을 관계의 주인으로 잡는다. 즉, 1 : N 관계의 경우 N쪽으로 주인으로 하는 것이다.

(일반적으로라고 했지만 항상 이를 따르자) 

그리고 이에 따라 아래와 같은 규칙들이 정해진다.

1. FK는 연관관계의 주인만이 관리한다.

2. 주인이 아닌 나머지 쪽은 FK에 대해 읽기만 수행할 수 있다.

3. 주인이 아닌 쪽에서 mappedBy 속성을 사용한다. (속성의 이름부터가 수동적인 느낌이라 주인에게는 어울리지 않는다. mappedBy = "관계의 주인") 

객체가 RDB에 매핑될 때 반드시 PK로 사용할 멤버변수를 지정해줘야 한다.

이때 @Id 어노테이션을 사용하는데, 이것만 사용할 경우 다른 컬럼들과 똑같이 PK값도 일일히 직접 할당해주게 된다.

보통 PK에 대해서는 이런 식으로 하지 않고 값이 알아서 자동적으로 할당되도록 하는 것이 좋다.

이를 위해 @Genera5tedValue 어노테이션을 추가로 사용하는데 여기에 적용되는 여러 가지 옵션이 있다.

그 중 가장 대표적인 방식은 IDENTITY, SEQUENCE 방식이다.

1. IDENTITY

@Entity 
public class Member { 
    @Id 
    @GeneratedValue(strategy = GenerationType.IDENTITY) 
    private Long id; 
}

PK의 생성을 데이터베이스가 대신 할당하도록 한다. 주로 MySQL에서 사용되는 방식이다.

(오라클은 IDENTITY 지원하지 않음)

IDENTITY 전략을 사용할 때 영속성 컨텍스트는 평소와는 조금 다르게 동작한다.

em.persist()로 영속성 컨텍스트에 객체를 저장하게 되면 해당 객체는 영속성 컨텍스트에 있는 1차 캐시 안에서 Key-Value 쌍으로 존재하게 된다.

이때 Key = PK, Value = Object의 형태로 존재하게 되는데.. IDENTITY 방식은 엔티티가 실질적으로 DB에 저장되는 순간 DB에서 자동으로 PK값을 할당해주는 방식이다.

하지만 트랜잭션이 커밋되기 전까지 해당 객체에 대한 쿼리는 DB에 적용되지 않는다. 

즉, 커밋이 이뤄지기 전까지는 PK를 가질 수 없다는 것. 그런데 영속성 컨텍스트 안에서는 PK-Object의 키밸류 페어로 존재해야 한다.

이를 해결하기 위해서 IDENTITY 전략을 사용할 때는 예외적으로 em.persist()를 호출했을 때 즉각적으로 DB에 실제 쿼리를 날려버린다.

2. SEQUENCE

@Entity 
@SequenceGenerator( 
        name = “MEMBER_SEQ_GENERATOR", 
        sequenceName = “MEMBER_SEQ", // 매핑할 데이터베이스 시퀀스 이름
        initialValue = 1, allocationSize = 1) 
public class Member { 
    @Id 
    @GeneratedValue(strategy = GenerationType.SEQUENCE, 
            generator = "MEMBER_SEQ_GENERATOR") 
    private Long id; 
}

SEQUENCE 전략은 DB의 시퀀스 오브젝트를 사용하여 PK값을 자동할당한다. 주로 오라클 디비에서 사용되는 방식이다.

(MySQL은 SEQUENCE 지원하지 않음)

이를 위해 @SequenceGenerator를 통해 사용할 시퀀스 오브젝트를 직접 생성해줘야 한다.

em.persist()를 수행하면 DB의 시퀀스 오브젝트에게서 1차캐시에 Key값으로 저장될 PK값을 할당받아 객체와 함께 영속성 컨텍스트 안에 저장한다.

(이떄 IDENTITY 전략 처럼 DB에 쿼리가 날아가는 것은 아니다)

하지만 PK 하나가 필요할 때마다 매번 디비쪽과 네트워크 통신을 하기 때문에 성능에 대한 문제가 있을 수 있다. 이를 방지하기 위해 @SequenceGenerator의 allocationSize 속성이 존재한다.

allocationSize는 한 번의 시퀀스 접근을 통해 사용할 수 있는 PK값의 개수를 의미한다.

allocationSize의 디폴트 값은 50인데, 이 경우 한 번의 DB 접근만으로 50개의 PK값을 얻어와 메모리에 저장한 뒤 영속성 컨텍스트에 객체를 저장할 때마다 메모리에서 PK를 하나씩 가져와 할당하는 것이다.

이렇게 하면 네트워크 접근 횟수를 비약적으로 줄일 수 있게 된다.

시퀀스 동작에 대한 좀 더 자세한 설명은 아래 질문글 링크를 참고

https://www.inflearn.com/questions/116520

EntityManager를 사용해 작업을 수행해도 commit을 하기 전까지는 작업의 결과들이 DB에 반영되지 않는다고 했었다.

정확히는 "Flush가 호출되기 전에는 DB에 반영되지 않는다"가 맞다.

Flush가 호출되면 영속성 컨텍스트 안에 보관되고있던 이전 작업들에 대한 결과가 실제 DB에 반영이 된다.

(영속성 컨텍스트를 비우는 것이 아니라 영속성 컨텍스트의 변경내용을 DB에 적용시켜 주는 것이다)

영속성 컨텍스트를 Flush하는 방법은 세 가지가 존재한다.

(사실 실전에서 직접적으로 도움이 되는 내용은 아니지만 테스트 등에서 사용될 수 있다)

1. em.flush()

-> 그냥 직접 호출하는 것이다.

2. transaction.commit()

-> 트랜잭션 커밋을 수행하면 플러시가 자동으로 호출된다.

3. JPQL

-> JPQL 쿼리를 실행하면 플러시가 자동으로 호출된다.

-> JPQL은 SQL로 번역되어 DB에 바로 접근하게 된다. 이 경우에 만약 영속성 컨텍스트의 내용이 DB에 적용되지 않은 상태로 JPQL이 수행된다면 문제가 발생할 수 있으므로 JPQL 전에는 항상 flush를 먼저 수행한다.

영속성 컨텍스트의 생존 범위는 반드시 트랜잭션과 함께 동작하도록 해야 한다.

스프링 프레임워크를 사용하면 스프링에 의해 트랜잭션이 종료될 때 영속성 컨텍스트도 함께 종료되도록 동작한다.

JPA는 왜 Java "Persistence" API인가? 바로 Persistence Context를 사용하기 때문.

맨 처음 웹 애플리케이션이 실행되면 EntityManagerFactory라는 녀석이 생성되고 그 후 사용자의 요청이 들어올 때마다 각각의 EntityManager를 만들어서 요청을 수행한다.

Persistence Context (영속성 컨텍스트)는 이 EntityManager안에 들어있는 녀석인데 이것이 자바 코드와 DB 사이에서 중간자 역할을 한다.

굳이 의미를 풀자면 "엔티티를 영구적으로 저장하는 환경" 정도가 된다.

객체를 엔티티로서 디비에 저장하거나 디비의 엔티티를 객체로 가져오는 명령을 내릴 때 해당 엔티티틑 영속성 컨텍스트 안에 존재하고 있다가 트랜잭션 커밋이 이뤄질 때 쿼리를 DB에 전달하여 동작을 완전히 수행한다.

이러한 영속성 컨텍스트 안에서 엔티티는 네 가지 생명주기를 갖는다.

1. 비영속 (new / transient)

-> 영속성 컨텍스트와 전혀 관계가 없는 상황. 새로 생성한 객체를 em.persist() 하기 전 이 객체는 '비영속' 상태에 해당된다.

2. 영속성 (managed)

-> 영속성 컨텍스트 안에서 관리되고 있는 상태. em.persist()를 하고난 이후의 객체가 '영속성' 상태에 해당된다.

3. 준영속 (detached)

-> 영속성 컨텍스트 안에 존재하다가 분리된 상태. em.persist(member)로 영속성 컨텍스트 안에 들어갔다가 em.detach(member)로 다시 분리하면 이때의 상태가 '준영속' 상태에 해당된다.

4. 삭제 (removed)

-> 객체를 완전히 삭제한 상태. 영속성 컨텍스트 안에 존재하는 객체에 대해 em.remove(member)하여 객체를 삭제하면 이 때의 상태가 '삭제' 상태이다.

비영속 상태와 준영속 상태는 같은 것이 아닌가 싶었는데 그에 대한 해답을 아래 링크에서 찾을 수 있었다.

www.inflearn.com/questions/45195      

영속성 컨텍스트 안에는 1차 캐시가 존재하여 캐싱을 지원한다.

그렇긴 한데 이게 실제 상황에서 그렇게 큰 시간절약을 이루어주지는 않는다고 한다.

단 건에 대한 기본적인 CRUD 기능은 아래와 같이 간편하게 사용할 수 있었다.

        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        Member member = new Member();
        member.setId(1L);
        member.setName("name1");
        
        // Create
        em.persist(member);  // list.add(Object o) 처럼 간편하게 DB에 객체 저장
        // Read
        Member findMember = em.find(Member.class, 1L);  // PK를 사용하여 간편하게 읽어옴
        // Update
        findMember.setName("change name");  // 조회한 객체에 대하여 수정을 하는 것만으로 update쿼리까지 완료됨
        // Delete
        em.remove(member);  // 조회한 객체를 삭제하면 테이블에서도 해당 엔티티 바로 삭제됨

        tx.commit();

그럼 좀 더 복잡한 경우에 대해서는 어떻게 해야할까? 

여러 개의 행을 반환해야 하거나 검색 조건을 넣어 조회를 해야한다면?

이런 경우에는 약간의 쿼리 작성이 필요하다. 하지만 DB 테이블을 기준으로 쿼리를 작성하지 않는다.

그게 무슨 말이지?

->

JPA의 존재 의의는 DB 테이블에 종속되지 않고 엔티티 객체 중심적으로 개발을 하기 위함이다.

그렇기에 부득이하게 쿼리를 짜야하는 일이 있어도 객체에 초점을 맞춰 쿼리를 작성한다.

만약 실제 물리적 DB에 맞춰 쿼리를 짠다면 그것은 DB에 종속적인 설계가 되는 것이고 이는 JPA의 사용 취지에 어긋난다.

// 여러 건의 검색 결과를 List에 담아 반환한다.
List<Member> result = em.createQuery("select m from Member as m", Member.class).getResultList();

위와 같은 문제를 해결하기 위해 JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공한다.

쿼리를 자세히 보면 지금까지 작성했던 쿼리와의 차이점을 알 수 있다.

from table_name이 아닌 from class_name의 형식으로 작성된 쿼리이다.

이런식으로 객체 중심적으로 쿼리를 작성하면 이 역시 JPA가 Member클래스에 해당하는 테이블명에 대한 쿼리를 알아서 날려서 조회를 해준다.

이렇게 객체 중심적으로 작성하는 쿼리를 JPQL(Java Persistence Query Language)라고 한다.

JPQL은 SELECT, FROM, WHERE, GROUP BY, HAVING, JOIN을 지원한다.

요즘은 NoSQL도 많이 사용한다지만 아직 가장 보편적인 데이터베이스는 RDB(Relational Database)이다.

객체지향 프로그래밍을 하면서 생성한 도메인 객체들은 관계형 데이터베이스에 저장되어서 관리된다.

즉, 도메인 클래스가 DB의 테이블과 대응되고 해당 클래스의 객체는 테이블의 엔티티로서 저장되는 것이다.

이를 위해서는 RDB 테이블에 해당 객체를 매핑(Mapping)시켜줘야 한다.

이를 ORM(Object Relational Mapping)이라고 한다.

고대(?) 자바 개발에서는 이 모든 작업을 JDBC를 통해 처리했다.

그런데 이 방법은 드라이버를 연결하고 SQL을 문자열로 하나하나 직접 작성하는 기계적이고 반복적인 작업에 소요되는 시간이 너무나 컸다.

너무나도 불필요한 낭비였지만 다른 대안이 없었기에 불가피했다.

또한 아무리 객체를 RDB에 매핑하여 저장한다지만 이 둘이 상속, 연관관계, 데이터 타입, 데이터 식별 방법 등 본질적인 패러다임까지 완전히 같은 것은 아니기에 여러 가지 문제들이 발생했다.

이런 배경 속에 등장한 것이 JPA(Java Persistence API)이다.

JPA는 객체를 마치 자바 Collections에 저장해 관리하는 것처럼 편리하게 DB에 저장할 수 있도록 해주는 ORM 프레임워크이다.

RDB는 RDB대로 그 특성에 맞게 설계하고 객체는 객체대로 설계한다. 사용자는 편하게 객체를 저장하고 귀찮은 매핑 작업은 전부 JPA가 처리한다.

즉, 패러다임의 불일치에 대해서 신경쓰지 않고 작업하는 것이다.

하지만 내부적으로는 여전히 JDBC가 사용된다. 사용자가 직접 사용하진 않게 되었지만 사용자 편하게 내린 명령을 JPA가 이전까지 해왔던 JDBC를 사용한 그런 복잡한 과정들을(SQL을 하나하나 작성하는 등) 거쳐 RDB에 매핑해주는 것이다.

기본적인 CRUD 기능에 대한 쿼리는 내부적으로 JPA가 전부 알아서 짜주기 때문에 더 이상 기계적, 반복적인 SQL 작업에 오랜 시간 고통받을 필요가 없어졌다.

JPA는 인터페이스의 모음이고 그것을 상속한 클래스가 여러 가지 존재하지만 hibernate가 대표적으로 사욯된다.

아래와 같은 방식으로 가장 기본적인 CRUD 기능을 쿼리 작성 없이 간단하게 사용할 수 있다.

        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        Member member = new Member();
        member.setId(1L);
        member.setName("name1");
        
        // Create
        em.persist(member);  // list.add(Object o) 처럼 간편하게 DB에 객체 저장
        // Read
        Member findMember = em.find(Member.class, 1L);  // PK를 사용하여 간편하게 읽어옴
        // Update
        findMember.setName("change name");  // 조회한 객체에 대하여 수정을 하는 것만으로 update쿼리까지 완료됨
        // Delete
        em.remove(member);  // 조회한 객체를 삭제하면 테이블에서도 해당 엔티티 바로 삭제됨

        tx.commit();

그런데, 위의 CRUD는 모두 하나의 객체에 대한 작업이다.

그럼 특정 조건의 엔티티 여러 개를 조회해야 하는 등 더 복잡한 경우엔 어떻게 할까?

이것을 위한 JPQL을 이 다음 글에서 설명한다.