SpringData 구조 및 JpaRepository 원리

출처 : 내일배움캠프

 

SpringData 구조

스프링 데이터 : 스프링을 위한 다양한 데이터 저장소 연동 및 최적화 패키지

Spring Data Common & JPA

- Repository : 특별한 기능은 없는 마커 어노테이션

- CrudRepository : CRUD 기능 제공

- PagingAndSortingRepository : 페이징, 정렬 부문에 대해 추가 기능을 제공하는 인터페이스

- Repository > CrudRepository > PagingAndSortingRepository > JPARepository까지 @NoRepositoryBean

: 중간 단계의 레포지토리가 실제 레포지토리가 아님을 알려 실제 Bean을 만들지 않도록 방지하는 기능

사용자 지정 레포지토리가 JPARepository<Entity, Id>를 상속하면 알맞게 프로그래밍 된 SimpleJPARepository 구현체 Bean이 되고, 스프링 구동시 빈으로 등록한다

+ @EnableJPARepositories(스프링 부트 사용시 자동 생성된다)의

JPARepositoriesRegistrar -> RepositoryBeanDefinitionRegistrarSupport : ImportBeanDefinitionRegistrar을 상속

 

@Repository vs @JPARepository

• Repository
  • **@Repository** 을 클래스에 붙인다.
  • 앞서배운 RawJPA의 Repository 기능만 가진 구현체가 생성된다. (DB별 예외처리 등)
• JpaRepository
  • JpaRepository<Entity,ID> 인터페이스를 인터페이스에 extends 붙인다.
    • @NotRepositoryBean 된 ****상위 인터페이스들의 기능을 포함한 구현체가 프로그래밍된다. (@NotRepositoryBean = 빈생성 막음)
    • SpringDataJpa 에 의해 엔티티의 CRUD, 페이징, 정렬 기능 메소드들을 가진 빈이 등록된다. (상위 인터페이스들의 기능)

Repository 기능 제한하기

1. @RepositoryDefinition

@RepositoryDefinition(domainClass = Thread.class, idClass = Long.class)
public interface ThreadRepository {

    Optional<Thread> findByThreadMessage(String message);

    // 다른 필드값으로 검색하는 것을 막는다 : 오로지 메세지 검색만 가능
}

2. @NoRepositoryBean 인터페이스로 한번 더 감싸는 법

@NoRepositoryBean
public interface UserRepository<User, ID extends Serializable> extends Repository<User, ID> {

    Optional<User> findByUsername(String username);
    // 이후 목표한 레포지토리가 이 인터페이스를 상속하게 한다 ~ 여기에 작성한 메서드만 사용가능하다
}

Repository 기능 추가하기

delete() 메소드

엔티티가 영속성 상태인지 확인하는 기본 delete() 메소드

영속성 상태여야 cascade, orphanremoval에 의해 자식 엔티티도 삭제되기 때문에 영속성 상태인지 확인하는 것이다

 

-> 연관관계 없고 성능 개선을 하고 싶다 : delete() 메서드 재정의하기

1. 기능 추가할 빈 인터페이스 작성

2. 그 인터페이스를 상속하고, delete 쿼리를 바로 날리도 메서드 재정의

 

JPA 프로세스

요청

----- 어플리케이션 -----

-> 쓰레드

 new 연산자를 통한 새로운 엔티티 생성 ~ 비영속성 상태인 객체, em.persist()로 영속성 부여 

-> 1차캐시(영속성 컨텍스트)

영속성이 부여된 엔티티가 1차 캐시에 등록된다, flush()로 DB transaction에 쿼리로 등록되게 한다 ~ 생성 insert 쿼리

----- 데이터베이스 -----

-> DB Transaction

Commit()이 발생하여 데이터베이스 원본에 Record로 저장이 된다

-> DB 원본

 

Detached, Remove로 상태 변환 등은 1차 캐시, 1차 캐시에서 일어난 일을 쓰기 지연 저장소에서 쿼리로 변환, DB transaction으로 전송 ~ Transaction 구간 1차 캐시와 DB transaction

 

+ 1차캐시 : App단 최적화 ~ 쓰기 지연 저장소의 쿼리를 계속 최적화, 쿼리는 이미 DB transaction에 저장되어 있다

+ 1차캐시에서 하는 롤백과 DB transaction에서 하는 롤백이 있다 (둘은 다르다)