🌈 [Section3] 8. [ Spring MVC ] Spring Data JPA 2

현주·2022년 11월 6일

spring mvc spring-data-jpa 실습 코드스테이츠

bootcamp

목록 보기

48/71

📕 오늘 배운 내용!

Spring Data JPA
JPQL / SQL
Audit / Fetch / CustomBeanUtils< T >

✏️ Spring Data JPA

Spring Data 패밀리 기술 중 하나
( Spring Data JDBC 도 이 중 하나 )
JPA 기반의 데이터 액세스 기술을 좀 더 쉽게 사용할 수 있게 해줌
➜ 데이터 액세스 계층의 구현에 있어 여러분의 개발 시간을 단축

💡 JPA vs Hibernate ORM vs Spring Data JPA
⠀⠀

JPA
➜ Jakarta Persistence API(또는 Java Persistence API)
➜ 엔터프라이즈 Java 애플리케이션에서 관계형 데이터베이스를 사용하기 위해 정해 놓은 표준 스펙(Specification)
( ’이 기술은 무엇이고, 이 기술은 이렇게 이렇게 구현해서 사용하면 돼’ 라고 적어 놓은 기술 명세라고 생각하면 됨 )
⠀⠀

Hibernate ORM
➜ JPA 스펙을 구현한 구현체
➜ 실제 우리가 사용할 수 있는 API
⠀⠀

Spring Data JPA
➜ JPA 스펙을 구현한 구현체의 API(일반적으로 Hibernate ORM)를 조금 더 쉽게 사용할 수 있도록 해주는 모듈
➜ 이를 사용하여 데이터 액세스 계층 구현

❗ 데이터 액세스 기술을 Spring Data JDBC에서 Spring Data JPA로 바꿨다고 해서 실제로 코드 자체가 대폭 변경된 부분은 없음
⠀
➜ 애플리케이션이 특정 기술에 강하게 결합되지 않도록 Spring이 추구하는 PSA(일관된 서비스 추상화)를 통해,
개발자는 일관된 코드 구현 방식을 유지하도록 하고, 기술의 변경이 필요할 때 최소한의 변경만을 하도록 지원한다

✔ 복잡한 검색 조건을 지정하기 위한 방법

( ❗ Repository 내의 find 메서드 위에 사용 )

✔️ 1. JPQL 사용

JPQL이라는 객체 지향 쿼리를 통해 데이터베이스 내의 테이블을 조회 가능
엔티티 클래스의 객체를 대상으로 객체를 조회하는 방법
( 테이블 대상으로 조회 X )
JPQL 문법을 이용하여 객체 조회하면, JPA가 내부적으로 JPQL을 분석 후 적절한 SQL을 만들어서 데이터베이스 조회, 그리고 그 조회한 결과를 엔티티 객체로 매핑 후 반환

Ex. @Query(value = "SELECT c FROM Coffee c WHERE c.coffeeId = :coffeeId")

coffeeId에 해당하는 커피 정보를 조회 ( SQL 문 아님 ! )

Coffee - 클래스명 / coffeeId - Coffee 클래스의 필드명 / c - Coffee 클래스의 별칭
⠀

위 쿼리문을 아래와 같이도 변경 가능 ( SELECT c를 생략한 형태 )
@Query(value = "FROM Coffee c WHERE c.coffeeId = :coffeeId")

[참고] https://en.wikibooks.org/wiki/Java_Persistence/JPQL
[참고] https://thorben-janssen.com/jpql/

✔️ 2. 네이티브 SQL을 통한 조회

SQL 쿼리 문법을 사용하여 데이터베이스 내의 테이블 조회

Ex. @Query(value = "SELECT * FROM COFFEE WHERE coffee_Id = :coffeeId")

nativeQuery 애트리뷰트의 값을 ‘true’로 설정하면 value 애트리뷰트에 작성한 SQL 쿼리가 적용

💡 Spring Data JDBC의 @Query vs Spring Data JPA의 @Query

애너테이션의 이름은 같지만 패키지 자체가 다름
➜ 패키지 경로를 혼동하지 않도록 주의해야 함
⠀⠀

Spring Data JDBC의 @Query 애너테이션 패키지 경로
import org.springframework.data.jdbc.repository.query.Query
⠀⠀

Spring Data JPA의 @Query 애너테이션 패키지 경로
import org.springframework.data.jpa.repository.Query

✔️ QueryDSL vs JOOQ
JPQL을 작성할 때, 복잡한 로직의 경우 쿼리 문자열이 상당히 길어짐
이 경우, 쿼리문 내엘 오타 / 문법적 오류가 있다면 런타임 에러 발생
➜ 이 문제를 어느정도 해소하는데 기여하는 프레임워크들임

[참고] https://tecoble.techcourse.co.kr/post/2021-08-08-basic-querydsl/
[참고] https://mycup.tistory.com/333

✔️ Audit 기능

데이터베이스에 데이터를 저장할 때, 생성일자 / 수정일자 등의 시간에 대한 중복 코드들에 자동으로 값을 넣어주는 기능
➜ Audit 기능을 이용하면 자동으로 시간을 매핑하여 데이터베이스의 테이블에 넣어주게 됨

@EnableJpaAuditing 애너테이션을 추가
- 보통 @SpringBootApplication 애너테이션이 추가된 클래스에 붙임
- JPA Configuration으로 별도로 구성하는 경우에 해당 클래스에 추가하는 경우 많음
@EntityListeners (AuditingEntityListener.class)
- 엔티티 상태 변경 감지 리스너
[참고] https://wave1994.tistory.com/161
@MappedSuperclass
- 객체 입장에서 공통 매핑 정보가 필요할 때 사용
- JPA Entity 클래스들이 이 애너테이션이 붙어 공통된 변수들을 정리해놓은 추상 클래스를 상속할 경우,
  해당 클래스의 변수인 createdDate / modifiedDate를 컬럼으로 인식
  
  ➜ 수퍼 클래스에 있는 필드에 포함되는 값들도 테이블에 반영하겠다는 의미
  
  [참고] https://ict-nroo.tistory.com/129
  - @createdDate
    • 엔티티 생성일시 자동 추가
  - @LastModifiedDate
    • 엔티티 수정일시 자동 추가
  - @createdBy
    • 엔티티 생성자 자동 추가
    • AuditorAware 인터페이스를 구현해 주어야 함

✔️ Fetch 전략

객체 그래프 탐색을 통해 연관 관계를 맺고 있는 객체를 어느 시점에 조회할 지를 결정하
는 전략

즉시 로딩 ( FetchType.EAGER )
- 엔티티를 조회할 때 데이터를 즉시 가져옴
- 연관관계로 매핑된 엔티티의 데이터까지 즉시 가져옴
- @ManyToOne / @OneToOne
지연 로딩 ( FetchType.LAZY )
- 데이터를 필요한 시점에 가져옴 ( 조회 X / 실제 사용할 때 )
  ➜ 연관관계로 매핑된 엔티티를 가져오는 메서드(getter)를 호출하는 시점에 가져옴
- @OnetoMany / @ManyToMany

✔️ 연관관계 매핑 애너테이션 별 디폴트 Fetch 전략

@ManyToOne / @OneToOne
- 즉시 로딩이 디폴트
  ➜ 연관된 엔티티가 하나일 경우 즉시 로딩
@OnetoMany / @ManyToMany
- 지연 로딩이 디폴트
  ➜ 연관된 엔티티가 여러개일 경우 지연 로딩

[참고] https://docs.jboss.org/hibernate/orm/5.6/userguide/html_single/Hibernate_User_Guide.html#fetching
[참고] https://rutgo-letsgo.tistory.com/199

[참고] https://velog.io/@sunho6824/%EC%98%81%EC%86%8D%EC%84%B1-%EC%A0%84%EC%9D%B4%EC%99%80-N1-%EB%AC%B8%EC%A0%9C

😜 실습

projects 폴더 내의 be-template-spring-data-jpa

이전 실습에 추가로 해야되는 부분
1. 엔티티 클래스를 Spring Data JPA에 맞게 수정
2. 리포지토리(Repository) 인터페이스 구현
3. 서비스 클래스 구현
4. 기타 기능 추가로 인해 수정 및 추가된 코드

✔️ CustomBeanUtils< T >

수정이 필요한 필드만 복사해서 업데이트 해주는 기능
Patch 정보의 경우 코드가 간결해지는 장점이 있음

Ex. 아래 MemberService 클래스의 updateMember() 메서드를 살펴보면,

정보를 가져와서 수정하는 부분이 Optional.ofNullable 로 길게 구현되어 있음

➜ 이는 수정해야할 정보들이 많을 수록 코드도 많아져 유지 보수 면에서 좋지 않음

따라서, CustomBeanUtils< T > 클래스를 사용하여 이를 간단하게 만들 것임

⬆️ 위와 같이 CustomBeanUtils< T > 클래스를 정의하고

⬆️ 이를 적용할 MemberService 클래스에 생성자로 주입을 한다 !

❗ 여기서 주의할 점은 먼저 변수로 지정할 때, CustomBeanUtils< T > 클래스가 제네릭으로 생성되어 있기 때문에 < > 안에 어떤 엔티티의 Service 클래스에 사용을 할지 적어줘야함 !

⬆️ 그리고 이를 적용할 MemberService 클래스 내의 updateMember() 메서드에

beanUtils 클래스 내의 copyNonNullProperties 메서드 사용하여 안에
(수정하고자 하는 정보, 넣을 메서드명)를 넣고
beanUtils.copyNonNullProperties(member, findMember);

이를 변수에 넣어 그 변수를 리턴하면 리팩토링 끝 !

......................................................................................................................................................................................................

✔️ ResponseDto 에서 우선되는 애너테이션

@Builder 패턴이 우선
@AllArgsConstructor 이 다음 우선
( 생성자에 모든 필드를 파라미터로 입력하는 방법 )
( @NoArgsConsturctor 면 매핑이 정상적으로 안됨 )
@Setter가 우선순위의 마지막

🌈 느낀점

실습 과제가 정말 수정할 부분이 많아서 어려웠는데 너무 좋은 페어님을 만나서 많이 배워가는 시간이었다 !!
직접 수정해나가면서 이해된 부분도 많았다.
물론 다 이해되진 않았지만 차차 보다보면 결국에 나중엔 다 이해되어 있겠지 !!
안되는 부분이 있어서 페어가 끝난 당일 저녁에도 만나서 수정하고, 그 다음 날에도 무려 8시간 반동안 같이 수정했다 !