반응형
Spring Data JPA 게시글은 대부분 인프런의 김영한님의 강의인 '실전! 스프링 데이터 JPA' 기반으로 내용을 정리했습니다.
스프링 데이터 JPA 구현체 분석
스프링 데이터 JPA가 내부적으로 어떻게 동작하는지 알아보기 위해 구현체를 분석해보자.
구현체는 JpaRepository 인터페이스에 인터페이스 선언부 옆에 화살표 아래 버튼을 누르면 SimpleJpaRepository를 찾을 수 있다.
@Repository
@Transactional(readOnly = true)
public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {
//...생략
@Override
public Optional<T> findById(ID id) {
Assert.notNull(id, ID_MUST_NOT_BE_NULL);
Class<T> domainType = getDomainClass();
if (metadata == null) {
return Optional.ofNullable(em.find(domainType, id));
}
LockModeType type = metadata.getLockModeType();
Map<String, Object> hints = new HashMap<>();
getQueryHints().withFetchGraphs(em).forEach(hints::put);
return Optional.ofNullable(type == null ? em.find(domainType, id, hints) : em.find(domainType, id, type, hints));
}
// ...생략
}구현체를 쭉쭉 보다보면 익숙하고, 반갑고, 고마운 메서드들이 보이면서 안의 코드도 볼 수 있다. 중요한 건 이게 아니라 맨 위에 있는 애노테이션이다.
@Repository
@Repository를 붙이면 얻을 수 있는 장점 두 가지가 있다.
첫 째로는 스프링 빈의 컴포넌트 스캔 대상이 된다. 그 말은 스프링이 읽어들여 스프링 컨테이너에 올릴 수 있게 된다.
두 번째로는 JPA, JDBC 등 예외가 터지면 영속성 계층에 있는 예외들을 스프링에서 한 번 감싸주어 서비스나 컨트롤러 계층에 예외를 던질 때 스프링에서 한 번 감싸준 예외로 던져진다. 이러면 하부 기술을 JDBC에서 JPA로 변경해도 스프링에서 한 번 감싸준 예외로 코드를 작성하니 기존 코드에 영향이 덜 간다는 장점이 있다.
@Transactional(readOnly=true)
- JPA의 모든 변경은 트랜잭션 안에서 동작한다.
- readOnly=true는 전반적인 설정이고, save와 같은 엔티티에 조회 외 다른 기능(등록, 수정, 삭제)을 지원하는 메서드에는 메서드 위에 @Transactional이라고 되어있어 이런 부분만 readOnly=false 처리가 된다.
@Transactional
@Override
public <S extends T> S save(S entity) {- 서비스 계층에서 트랜잭션을 시작하지 않으면 리파지토리에서 트랜잭션이 시작된다.
- 서비스 계층에서 트랜잭션을 시작하면 리파지토리는 해당 트랜잭션을 전파 받아서 사용한다.
- 그래서 스프링 데이터 JPA를 사용할 때는 트랜잭션을 따로 설정 안해도 데이터 등록, 변경이 가능하다.
save()
@Transactional
@Override
public <S extends T> S save(S entity) {
Assert.notNull(entity, "Entity must not be null.");
if (entityInformation.isNew(entity)) { // 만약 새로운 엔티티면
em.persist(entity);
return entity;
} else { // 새로운 엔티티가 아니면
return em.merge(entity);
}
}- 새로운 엔티티면 저장(persist)
- 새로운 엔티티가 아니면 병합(merge)
- save()의 단점은 새로운 엔티티인지 아닌지를 알기 위해 DB에 select를 할 수 밖에 없다는 것이다.
반응형