🌈 [Section3] 7. [ Spring MVC ] Spring Data JPA 1

📕 오늘 배운 내용!

• JPA (Java Persistence API)
• 엔티티 매핑

---

✏️ JPA (Java Persistence API)

• Java 진영에서 사용하는 ORM(Object-Relational Mapping) 기술의 표준 사양(Specification)
• Jakarta Persistence 라고도 불림
• 테이블과 매핑되는 엔티티 객체 정보를 영속성 컨텍스트(Persistence Context)에 보관하여 애플리케이션 내에서 오래 지속 되도록 함
  ⠀⠀
  ➜ 인터페이스로 JPA라는 표준 사양이 정의되어 있기 때문에, 이 사양을 구현한 구현체는 따로 있음
  ( 우리는 이 사양을 구현한 구현체에 대해 학습하는 것 )

💡 사양 (Specification)
➜ 설계구조 / 기술 설명서 등을 의미

✔️ JPA 표준 사양을 구현한 구현체
Hibernate ORM, EclipseLink, DataNucleus 등
( 우리는 여기서 Hibernate ORM 에 대해서 학습 )
[참고] https://docs.jboss.org/hibernate/orm/6.0/javadocs/

❗ Spring Data JPA 기술을 포함한 JPA API사용을 위해서는
build.gradle 파일의 dependncies 내에 아래와 같은 의존성 추가해야함 ⬇️

implementation 'org.springframework.boot:spring-boot-starter-data-jpa'

( Spring Data JPA가 아닌 JPA API만 사용하고 싶다면 JPA 관련 의존 라이브러리를 별도로 추가 )

 

✔ JPA의 4가지 Lifecycle 상태

[참고] https://thorben-janssen.com/entity-lifecycle-model/

 

✔ 데이터 액세스 계층에서의 JPA 위치

• 데이터 액세스 계층의 상단에 위치
  • 데이터 저장, 조회 등의 작업은 JPA를 거쳐 JPA의 구현체인 Hibernate ORM을 통해서 이루어짐
  • Hibernate ORM은 내부적으로 JDBC API를 이용해서 데이터베이스에 접근

 

✔️ 영속성 컨텍스트(Persistence Context)

• 테이블과 매핑되는 엔티티 객체 정보를 보관
  ➜ 애플리케이션 내에서 오래 지속 되게 하고, 이 보관된 엔티티 정보는 데이터베이스 테이블에 데이터를 CRUD 하는데 사용됨
  
  
• 1차 캐시 / 쓰기 지연 SQL 저장소로 구분
  ➜ JPA API 중 persist() 메서드 사용하면, 1차 캐시에 엔티티 정보 저장됨

💡 쓰기 지연 SQL 저장소
➜ 개념적으로는 저장소라고 표현했지만,
내부적으로는 Entity 기반으로 SQL 쿼리문이 commit 하는 시점에 동적으로 생성되는 것을 말함

---

✏️ 엔티티 매핑 종류

• 엔티티 - 테이블 간 매핑
• 기본키 매핑
• 엔티티필드(멤버 변수) - 테이블 컬럼 간 매핑
• 엔티티 - 엔티티의 연관 관계 매핑

---

✏️ 엔티티 - 테이블 간 매핑

✔️ @Entity

• 엔티티 클래스와 테이블 매핑하는 애너테이션 (필수)
  ➜ @Id와 꼭 함께 필수로 사용

💡 @Entity만 붙이고 @Id 안붙일 경우
Caused by: org.hibernate.AnnotationException: No identifier specified for entity: com.codestates.entity_mapping.single_mapping.Member 이 에러 발생

• 클래스 레벨에 붙임
  ➜ JPA 관리 대상 엔티티가 됨
  
  
• 애트리뷰트 name 사용 가능
  ➜ 엔티티의 이름 설정
  ( 설정 안하면 클래스명을 엔티티 이름으로 함 )

Ex. @Entity(name = "USERS")

💡 @Entity 주의 사항

• 접근 제어자가 public / protected인 기본 생성자가 필수
• final 클래스, enum, interface, inner 클래스에는 사용이 불가
• 저장하려는 속성은 final X

✔️ @Table

• 엔티티 클래스와 테이블 매핑하는 애너테이션 (옵션)
• 클래스 레벨에 붙임
• 애트리뷰트 name 사용 가능
  ➜ 데이터베스의 테이블 이름 설정
  ( 설정 안하면 클래스명을 테이블 이름으로 함 )

✔️ @Entity(name = "") vs @Table(name = "")
@Entity(name = "")는 Entity를 식별할 이름을 정하는 것이고,
@Table(name = "")는 데이터베이스에 생성될 Table의 이름을 정하는 것
⠀
❗ @Table이 없고 @Entity(name ="")만 존재하는 경우,
@Entity의 name 속성에 의해, Entity와 Table 이름이 모두 결정
[참고] https://www.inflearn.com/questions/75556
⠀
❗ @Table 애너테이션은 옵션이지만, @Entity 애너테이션과 @Id 애너테이션은 필수

✔️ @NoArgsConstructor

• 파라미터가 없는 기본 생성자 필수로 추가
  ( Spring Data JPA의 기술을 적용할 때 기본 생성자가 없는 경우 에러가 발생하는 경우가 있음 )

---

✏️ 기본키 매핑

✔️ @Id

• 이 애터테이션을 추가한 필드가 기본키(Primary Key) 컬럼이 됨

✔️ @GeneratedValue(strategy = GenerationType.생성방법)

• 기본키 생성 방법을 정해줄 때 사용하는 애너테이션

✔️ 기본키 생성 전략

1. 기본키 직접 할당

• 애플리케이션 코드상에 직접 할당해주는 방식
• @Id 애너테이션 사용하는 방식
  ( 아래는 DIRECT 방식의 출력 결과 )

2. 기본키 자동 생성

• IDENTITY
  ➜ 데이터베이스에 기본키 생성을 위임하는 방식
  Ex. MySQL의 AUTO_INCREMENT 기능 ( 기본키의 숫자가 자동으로 +1 )
  ➜ commit() 전 까지는 영속성 컨텍스트의 1차 캐시에서 식별자가 없는 객체만 가지고 있다가, commit() 하면서 테이블에 데이터가 저장될 때 식별자도 동시에 생겨서 테이블에 들어감 ➜ 이 후, 1차 캐시의 객체에도 그 식별자가 적용됨
  ( 아래는 IDENTITY 생성 방식의 출력 결과 )

• SEQUENCE
  ➜ 데이터베이스에서 제공하는 시퀀스를 사용해 기본키를 생성하는 방식
  ➜ 데이터를 테이블에 저장하기 전에 영속성 컨텍스트의 1차 캐시 내에 저장되어 있는 객체에 시퀀스로 가져온 식별자를 채워 넣음 ➜ commit() 하면 테이블에 식별자 바로 채워짐
  ( 아래는 SEQUENCE 생성 방식의 출력 결과 )

• TABLE
  ➜ 키 생성 전용 TABLE을 별도로 만들고, 키를 조회/업데이트 하는 쿼리를 추가적으로 전송해야해서 성능면에서 좋은 선택 X
  ⠀
  ❗ IDENTITY / SEQUENCE 방식을 사용하는 것이 좋음

1.  

---

✏️ 엔티티 필드(멤버 변수) - 테이블 컬럼 간 매핑

✔️ @Column

• 필드와 컬럼을 매핑해주는 애너테이션

💡 @Column 애너테이션이 없고 필드만 정리되어 있다면,
JPA 는 기본적으로 이 필드가 테이블의 컬럼과 매핑되는 필드라고 간주함
( 애트리뷰트는 디폴트 값이 적용됨 )

---

💡 @Column 애너테이션이 생략되었거나 애트리뷰트가 기본값을 사용할 경우 주의 사항

@Column(nullable = true, updatable = true, unique = false)
여기서 nullable 값의 디폴트가 true인데
이 경우, 필드의 데이터 타입이 int, long 값은 Java의 원시 타입일 경우 null 값 입력 불가!
( null은 객체 타입일 경우에만 적용되니까 )

➜ ❗ 최소한 nullable=false는 설정하여 에러 방지하기 !!

• 변수마다 적어야함
  ➜ 번거롭긴 하지만 테이블 설계가 어떤 식으로 되어있는지 한눈에 확인 가능

✔️ @Column의 애트리뷰트

• nullable
  ➜ 컬럼에 null 값 허용할지 여부 ( 디폴트 - true ) / email 은 로그인 ID 로 많이 사용되어 필수기 때문에 false 로 지정함
  ⠀
• updatable
  ➜ 컬럼 데이터를 수정할 수 있는지 여부 지정 ( 디폴트 - true )
  Ex. email을 로그인 ID 로 사용한다고 가정하고 등록하면 수정 불가이기 때문에 false 로 지정해야함
  ⠀
• unique
  ➜ 하나의 컬럼에 유니크 제약 조건 설정(고유한 값으로 설정) ( 디폴트 - false )
  Ex. email은 고유 값이므로 true로 지정
  ⠀
• length
  ➜ 컬럼에 저장할 수 있는 문자 길이 지정 ( 디폴트 - 255 )
  ⠀
• name
  ➜ 엔티티 클래스 필드명과 다른 이름으로 컬럼을 생성 가능
  ⠀
  [참고] https://docs.oracle.com/javaee/7/api/

✔️ @Transient

• 이 애너테이션 추가하면 테이블 컬럼과 매핑하지 않겠다는 의미로 JPA 가 인식
  ➜ 데이터 베이스에 저장 X / 조회할 때 매핑 X
  (주로 임시 데이터를 메모리에서 사용하기 위한 용도)

✔️ @Enumerated(EnumType.타입) / @Enumerated(values = EnumType.타입)

• enum 타입과 매핑할 때 사용하는 애너테이션
• 아래의 두가지 Enum타입을 가질 수 있음

✔️ EnumType 종류

• ORDINAL
  ➜ enum의 순서를 나타내는 숫자를 테이블에 저장
  Ex. 우리 실습에서 enum orderStatus() 안의 상태를 4개를 지정했는데,
  이게 String으로 저장되는 것이 아니라 숫자로 인덱스처럼 저장됨
  But, 이 경우 중간에 새로운 enum 하나가 추가되면 순서,번호가 이상해져서 잘 사용 X
  ⠀⠀
• STRING
  ➜ enum의 이름을 테이블에 저장
  ⠀
  ❗ EnumType.STRING 사용 권장

---

✏️ 엔티티 - 엔티티의 연관 관계 매핑

• 보통 다(N)에 해당하는 클래스에 일(1)에 해당하는 객체를 외래키로 가져오는 방식 !
  
  
• 단방향 연관 관계
  ➜ 한쪽 클래스만 다른 쪽 클래스의 참조 정보를 가지고 있는 관계
  
  
• 양방향 연관 관계
  ➜ 양쪽 클래스가 서로의 참조 정보를 가지고 있는 관계

💬 무조건 양방향 관계를 하면 쉽지 않을까?
NO. 불필요한 연관관계로 오히려 엔티티가 복잡해질 수 있음

Ex. 사용자(User) 엔티티가 많은 엔티티와 연관관계를 가지는데,
이 경우 모든 클래스와 양방향 관계로 매핑을 한다면 User 클래스 내의 코드의 복잡성이 증가할 것

➜ ❗ 기본적으로 단방향 매핑을 하고 후에 필요가 있다고 생각되면 역방향 매핑을 추가

💡 JPA vs Spring Data JDBC 의 방향성

• JPA
  ➜ 단방향 연관 관계와 양방향 연관 관계를 모두 지원
  ⠀
• Spring Data JDBC
  ➜ 단방향 연관 관계만 지원

---

✔️ 일대다 단방향 연관 관계 ( One To Many )

• 일(1)에 해당하는 클래스가 다(N)에 해당하는 객체를 참조할 수 있는 관계
  
  

Ex. 한명의 회원이 여러 건의 주문
➜ Member 클래스에 Order의 List가 참조되어 있는 모습

❗ But, 일대다 단방향 연관 관계는 잘 사용 X
테이블 간 관계로 보았을 때,
다(N)에 해당하는 테이블이 일(1)에 해당하는 테이블의 기본키를 외래키로 가지는 형태인데,
기본 객체 참조 관계로 보았을 때,
일(1)에 해당하는 클래스가 다(N)에 해당하는 객체를 참조받기 때문에
다(N)의 입장에서는 테이블에서 외래키에 해당하는 일(1) 객체의 참조값을 가지고 있지 않아서 일반적인 테이블 간 관계 표현 X
➜ 다(N) 클래스의 정보를 테이블에 저장하더라도 외래키에 해당하는 일(1) 클래스의 id 값이 없는 채로 저장이 됩

➜ ❗ 다대일 단방향 매핑을 먼저 한 후에 필요한 경우,

일대다 단방향 매핑을 추가해서 양방향 연관 관계를 만드는 것이 일반적

💬 궁금했던 점 !!!

위의 단방향 일대다 매핑에서 Member(1) 클래스에 Order(N) 객체가 List로 참조가 되어있는데,
여기서 @JoinColumn(name = "") 애너테이션은 외래키의 명을 정해주는 것이고, Member(1)가 외래키로 Order(N)에 참조되어야 하기 때문에 그래서 외래키의 이름을 MEMBER_ID로 하는 것이다.
그런데, Member 클래스 내에 Order 객체를 List로 가져왔는데
왜 그 Order 객체의 pk를 MEMBER_ID라는 외래키 이름으로 설정하는 건지 잘 이해가 가지 않았다.

---

💬 Answer )

보면 이상하지만, 단방향이기 때문에 Order에서는 Member를 참조하지 않음
그래서 @JoinColumn을 그쪽에 추가하려고해도 추가할 수 없음
따라서 Member 쪽에서 연관 관계를 맺어주는 쪽에 추가해주는 것 !
⠀
➜ 단뱡향이라서 한쪽에다만 모두 넣어야하니까 Order도 참조 하고,
참조가 될 외래키인 Member(1)클래스의 memberId도 MEMBER_ID라는 이름으로 추가해주는 것 !

 

---

✔️ 다대일 연관 관계 ( Many To One ) ⭐

• 다(N)에 해당하는 클래스가 일(1)에 해당하는 객체를 참조할 수 있는 관계
• 가장 기본으로 사용되는 매핑 방식

Ex. 한명이 여러건의 주문

➜ Order 클래스에 member가 참조되어 있는 모습

• @ManyToOne 애너테이션으로 다대일 관계를 명시해줌
• @JoinColumn(name = "외래키명") 애너테이션으로 외래키 이름 설정
• 참조될 Member 객체를 가져옴

➜ Member 클래스에 Order가 List로 참조되어 있는 모습

• @OneToMany 애너테이션으로 일대다 관계를 명시해줌
• 위 애너테이션의 애트리뷰트로 (mappedBy = "외래키 역할하는 필드")를 넣어주어 외래키의 역할을 하고 있음을 알려줌
• 참조를 받는 Order 객체를 List로 가져옴
  ( 한 회원이 여러 주문 가능이니까 )

💡 mappedBy에 오는 값이 헷갈릴 때 !

1. 두 객체들 간에 외래키의 역할을 하는 필드는 무엇인가?
2. 외래키의 역할을 하는 필드는 다(N)에 해당하는 클래스 안에 있음
   ⠀
   이 두가지를 생각해보면 쉬움!

---

✔️ 다대다 연관 관계 ( Many To Many ) ⭐

• @ManyToMany 애너테이션을 사용하지 않고 Join 테이블과 같은 클래스를 하나 더 만들어 1-N-1 관계로,
  다대일 관계를 두번 설정하면 됨!

❗ @ManyToMany 애너테이션을 써서 따로 클래스를 만들지 않고 연관 관계를 맺어줄 수 있지만, 이 경우 중간에 값이 추가가 안되기 때문에 사용 X

Ex. Coffee 클래스와 Order 클래스가 있을 때,
한 커피를 여러명이 주문 가능 / 한명이 여러 커피 주문 가능 ➜ 다대다 관계

➜ 이를 다대일 관계로 풀어줄 OrderCoffee 클래스 생성

결국 관계는 Coffee(1) - OrderCoffee(N) / OrderCoffee(N) - Order(1) 이 되는 것!

이 후는 다대일 관계와 같이 진행하면 됨 !

➜ OrderCoffee 클래스에 Order / Coffee가 참조되어 있는 모습

➜ Order 클래스에 OrderCoffee가 참조되어 있는 모습

➜ Coffee 클래스에 OrderCoffee가 참조되어 있는 모습

---

✔️ 일대일 연관 관계 ( One To One )

• @OneToOne 애너테이션을 사용하고,
  다대일 양방향 매핑 처럼 외래키가 있는 곳이 연관 관계의 주인
  ( 이 외래키를 어디에 두느냐는 우리가 정하기 나름 ! )
  
  

Ex. 한명의 회원이 한개의 스탬프를 찍을 수 있다고 할 때,

나는 Stamp가 Member의 외래키를 가지고 있다고 생각하여 아래와 같이 만들었다

➜ Stamp 클래스에 Member가 참조되어 있는 모습

➜ Member 클래스에 Stamp가 참조되어 있는 모습

[참고] https://beagle-dev.tistory.com/306

💡 연관 관계의 주인

• 양방향 관계일 때 연관 관계의 주인을 지정해야함
  ( 두 단방향 관계 중, 제어의 권한(저장,수정,삭제 등)을 갖는 실질적인 관계의 주체가 누구인지 JPA에게 알려주는 것 )
  ➜ mappedBy 속성을 사용해서 주인을 지정
  ⠀
  ❗ 외래 키가 있는 곳 = 연관 관계의 주인 !!

💡 연관 관계의 주인을 지정해야하는 이유

• 테이블의 매핑을 담당하는 JPA 입장에서 두 클래스 중 어느 것을 수정해야할 지 혼란을 주게 됨
  ➜ 연관 관계의 주인을 정해 명확하게 어느 클래스에서 뭐를 수정하겠다고 정하는 것 !

 

✔ 영속성 전이

• 특정 엔티티를 영속성 컨텍스트에서 관리할 때 연관된 엔티티도 같이 관리하고자 하는
  것
  ( 연관된 엔티티의 정보까지 한꺼번에 조회하거나 삭제하는 등의 동작 할 수 있음 )
  
  
• 연관관계 매핑 애너테이션의 cascade 애트리뷰트로 설정
  Ex. @OneToOne(mappedBy = "member", cascade = CascadeType.PERSIST)

✔️ Cascade Type 종류

• PERSIST
  • 연관된 엔티티까지 영속화시킴
• REMOVE
  • 연관된 엔티티까지 영속성 컨텍스트에서 제거
• MERGE
  • 영속 상태의 엔티티와 준영속 상태의 엔티티를 병합할 때 연관된 엔티티까지
    병합을 적용
• REFRESH
  • 엔티티를 다시 읽어 올 때, 연관된 엔티티까지 다시 읽어옴
• DETACH
  • 연관된 엔티티까지 준영속화(Detach)
    [참고] https://docs.jboss.org/hibernate/orm/5.6/userguide/html_single/Hibernate_User_Guide.html#pc-cascade

---

✏️JPA API

private EntityManager em;
// JPA 의 영속성 컨텍스트는 EntityManager 인터페이스에 의해서 관리됨
private EntityTransaction tx;
// 이 객체를 기준으로 데이터를 데이터베이스 테이블에 저장

✔️ tx.begin();

• Transaction 시작을 위한 메서드 호출

✔️ em.persist(new 객체(값));

• 객체를 영속성 컨텍스트에 저장
• 이 메서드 호출 시, 1차 캐시에 객체가 저장되고, 이 객체는 쓰기 지연 SQL 저장소에 INSERT 쿼리 형태(INSERT ...(객체명))로 등록됨

But, 실제 테이블에는 이 정보를 저장하지 않고, 실제 로그에도 INSET 쿼리 안보임
➜ commit()으로 따로 저장해줘야 함

❗ 순서 주의하면서 persist() 해야함 !

Ex. Coffee(1) / Order(1) / OrderCoffee(N) 클래스가 있을 때,
OrderCoffee 클래스는 Coffee와 Order의 외래키를 참조받고 있기 때문에
Coffee / Order 보다 늦게 persist() 해야함

✔️ em.find(조회할 엔티티 클래스 타입, 조회할 엔티티 클래스의 식별자 값);

• commit()으로 테이블에 저장된 객체를 영속성 컨텍스트의 1차 캐시에서 조회
  ( 테이블에서 조회 X )

✔️ em.remove();

• 영속성 컨텍스트의 1차 캐시에 있는 엔티티 제거 요청
  ➜ 쓰기 지연 SQL 저장소에 DELETE 쿼리 등록

✔️ em.flush();

• commit() 메서드 호출시 JPA 내부적으로 em.flush() 메서드가 호출되어 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영

✔️ tx.commit();

• 영속성 컨텍스트의 쓰기 지연 SQL 저장소에 등록된 쿼리 실행
  ➜ 데이터베이스에 데이터 저장

---

😜 실습

• projects 내의 be-template-jdbc 2

위 사진과 같이 yml 파일에 아래 두개 추가해주기 !

• ddl-auto: create
  ➜ 스키마 자동 생성
  ( 엔티티 클래스와 매핑되는 테이블을 데이터베이스에 자동 생성해줌 )
  ( schema.sql 파일 생성 필요 X )
  
  
• show-sql: true
  ➜ SQL 쿼리 출력
  ( JPA API 를 통해서 실행되는 SQL 쿼리를 로그로 출력 )
  ( 동작 과정 이해 쉬움 )
  
  

클래스를 생성하여 내부 코드를 작성하고 출력하면 아래와 같이 테이블이 자동생성된 것을 볼 수 있음 !

아래는 find() 메서드로 ID가 1인 Member의 email 주소를 영속성 컨텍스트에서 조회하고있는 것 확인 가능 !

application.yml 파일에 아래와 같이 추가한다면

spring: //이건 이미 쓰여 있음
  jpa: //이것도 쓰여 있음
    properties: //추가
      hibernate: //추가
        format_sql: true //추가

위의 예시 사진들과 같이 한줄로 밋밋했던 로그들을 아래와 같이 예쁘게 보기 가능 !!

[참고] https://lannstark.tistory.com/14

---

아래의 코드를 실행하면,

Member resultMember2 = em.find(Member.class, 2L);
//식별자 값이 2L 인 member 객체 조회
//조회된 객체가 없다면 테이블에도 SELECT 쿼리 전송하여 조회

System.out.println(resultMember2 == null); //위에서 조회하는 객체가 없으니까 이 결과 true

 

SELECT 쿼리가 실행된 것을 볼 수 있고,

이 SELECT 쿼리를 통해 em.find(Member.class, 2L)로 조회를 했는데

식별자 값 2L에 해당하는 member2 객체가 영속성 컨텍스트의 1차 캐시에 없기 때문에

추가적으로 테이블에서 한번 더 조회한다는 것 알 수 있음

---

아래와 같은 메서드를 실행시키면,

private void example03() {
    tx.begin();

    Member member1 = new Member("hgd@gmail.com");
    Member member2 = new Member("hgd@gmail.com");

    em.persist(member1);
    em.persist(member2);
    //member1, member2 객체를 영속성 컨텍스트에 저장
    //--> 1차 캐시 - member2 객체 / 쓰기 지연 SQL 저장소 - INSERT ...(member2)
    //--> 테이블에는 저장 X

    tx.commit();
    //영속성 컨텍스트의 쓰기 지연 SQL 저장소에 있던 INSERT 쿼리문 실행
    //--> 데이터베이스에 데이터 저장
}

아래와 같이 출력 결과에 두 member 객체가 저장된 것을 알 수 있음!

++추가로

@Setter 애너테이션을 클래스 레벨에서 사용하는 것은 바람적이지 않음 !

해당 클래스의 식별자(Id)처럼 수정이되면 안되는 정보는 바뀌지 않아야하는데

클래스 레벨에 @Setter 애너테이션을 붙일 경우 변경될 수 있음 !

➜ @Setter 애너테이션은 수정이 필요한 필드(메서드) 레벨에만 사용하는 것이 바람직 !

---

🌈 느낀점

확실히 JDBC 보다 쉽고 그래서 그런지 재밌다 !!
뭔가 이해도 잘 되고 정리도 더 잘 되는 느낌
JDBC 에서는 아직 이해 못한 부분이 있지만 시간이 없어서 일단 넘어갔었는데,
실무에서는 JPA를 보통 사용한다고 하니 정말 다행이다 ㅎㅎ

 

( 본 게시물은 2022/11/03에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90