[스프링 부트와 AWS로 혼자 구현하는 웹 서비스] 3장. 스프링 부트에서 JPA로 데이터베이스 다뤄보자

'스프링 부트와 AWS로 혼자 구현하는 웹 서비스'를 읽고 정리한 글입니다.

---

 

ORM은 객체를 매핑하는 것이고, SQL Mapper는 쿼리를 매핑한다.

 

JPA 소개

---

현업 프로젝트 대부분이 애플리케이션 코드보다 SQL이 더 많다.

 

이는 관계형 데이터베이스가 SQL만 인식할 수 있기 때문인데, 각 테이블마다 기본적인 CRUD SQL을 매번 생성해야 한다.

insert into user (id, name, ...) values (...);
select * from user where ...;
update user set ... where ...;
delete from user where ...;

이러한 SQL들을 반복적으로 수백 개의 테이블의 수 배의 SQL을 만들고 유지보수해야 한다.

 

이런 반복 작업의 문제 외에 패러다임 불일치 문제가 있다.

 

관계형 데이터베이스는 어떻게 데이터를 저장할지에 초점이 맞춰진 기술이다.

 

객체지향 프로그래밍 언어는 메시지를 기반으로 기능과 속성을 한 곳에서 관리하는 기술이다.

 

관계형 데이터베이스와 객체지향 프로그래밍 언어의 패러다임이 서로 다르다는 것이다.

 

관계형 데이터베이스로 객체지향을 표현할 수 있을까?

 

서로 패러다임이 다른데, 객체를 데이터베이스에 저장하려고 하니 여러 문제가 발생한다.

이를 패러다임 불일치라고 한다.

객체지향 프로그래밍에서 부모가 되는 객체를 가져오려면 어떻게 해야 할까?

User user = findUser();
Group group = user.getGroup();

명확하게 User와 Group은 부모-자식 관계임을 알 수 있다.

 

여기에 데이터베이스가 추가되면 다음과 같이 변경된다.

User user = userDao.findUser();
Group group = groupDao.findGroup(user.getGroupId());

User 따로, Group따로 조회하게 된다. 여기서 User와 Group이 어떤 관계인지 알 수 있을까?

상속, 1:N 등 다양한 객체 모델링을 데이터베이스로 구현할 수 없다.

그러다 보니 웹 어플리케이션 개발은 점점 데이터베이스 모델링에 집중하게 된다.

 

JPA는 이런 문제점을 해결하기 위해 등장한다.

 

JPA는 서로 지향하는 바가 다른 2개 영역(OOP와 RDB)을 중간에서 패러다임 일치를 시켜주기 위한 기술이다.

 

즉, 개발자는 객체지향적으로 프로그래밍을 하고, JPA가 이를 관계형 데이터베이스에 맞게 SQL을 대신 생성해서 실행한다. JPA를 이용함으로써 개발자는 SQL에 종송적인 개발을 하지 않아도 된다.

 

객체 중심으로 개발을 하게 되니 생산성 향상은 물론 유지 보수하기가 편하다.

이런 이유로 규모가 크고 365일 24시간, 대규모 트래픽과 데이터를 가진 서비스에서 JPA는 표준 기술로 자리 잡고 있다.

 

Spring Data JPA

• JPA는 인터페이스로서 자바 표준명세서이다.
• 인터페이스인 JPA를 사용하기 위해 구현체가 필요하다.
• 대표적으로 Hibernate, Eclipse, Link 등이 있다.
• Spring에서 JPA를 사용할 때 이 구현체들을 직접 다루지 않는다.

구현체들을 좀 더 쉽게 사용하고자 추상화 시킨 Spring Data JPA라는 모듈을 이용하여 JPA 기술을 다룬다.

• JPA  ← Hibnernate ← Spring Data JPA

Hibernate를 쓰는 것과 Spring Data JPA를 쓰는 것 사이에는 큰 차이가 없다.

그럼에도 Spring Data JPA를 개발했고, 이를 권장하고 있다.

 

이렇게 한 단계 더 감싸놓은 Spring Data JPA가 등장한 이유는 크게 두 가지가 있다.

• 구현체 교체의 용이성
• 저장소 교체의 용이성

구현체 교체의 용이성이란 Hibernate 외에 다른 구현체로 쉽게 교체하기 위함이다.

Hibernate 외에 새로운 JPA 구현체가 대세로 떠오를 때, Spring Data JPA를 쓰는 중이라면 쉽게 교체할 수 있다.

➜ Spring Data JPA 내부에서 구현체 매핑을 지원해주기 때문이다.

 

저장소 교체의 용이성이란 관계형 데이터베이스 외에 다른 저장소로 쉽게 교체하기 위함이다.

트래픽이 많아져 관계형 데이터베이스로는 감당히 안될 때가 올 수 있다.

이때 MongoDB로 교체가 필요하다면 개발자는 Spring Data JPA에서 Spring Data MongoDB로 의존성만 교체하면 된다.

➜ 이는 Spring Data의 하위 프로젝트들은 기본적인 CRUD의 인터페이스가 같기 때문이다.

즉, Spring Data JPA, Spring Data Redis, Spring Data MongoDB 등등 Spring Data의 하위 프로젝트들은 save(), findAll, findOne() 등을 인터페이스로 갖고 있다. 그러다 보니 저장소가 교체되어도 기본적인 기능은 변경할 것이 없다.

 

실무에서 JPA

실무에서 JPA를 사용하지 못하는 가장 큰 이유로 높은 러닝 커브를 이야기한다.

JPA를 잘 쓰려면 객체지향 프로그래밍과 관계형 데이터베이스를 둘 다 이해해야 한다.

 

하지만 JPA를 사용해서 얻는 보상은 크다.

• CRUD 쿼리를 직접 작성할 필요가 없다.
• 부모-자식 관계 표현, 1:N 관계 표현, 상태와 행위를 한 곳에서 관리하는 등 객체지향 프로그래밍을 쉽게 할 수 있다.

JPA의 성능 이슈 해결책들을 활용하면 네이티브 쿼리만큼의 퍼포먼스를 낼 수 있다.

 

 

요구사항 분석

---

앞으로 게시판을 만들어 보고 AWS에 무중단 배포 하는것까지 진행한다.

 

요구사항

 

구현한 결과 화면

이제 기능들을 만들어보자.

 

 

Spring Data Jpa 적용하기

---

build.gradle

jpa와 com.h2database:h2 의존성 등록

spring-boot-starter-data-jpa

• 스프링 부트용 Spring Data Jpa 추상화 라이브러리
• 스프링 부트버전에 맞춰 자동으로 JPA관련 라이브러리들의 버전을 관리해 준다.

h2

• 인메모리 관계형 데이터베이스
• 별도의 설치가 필요 없이 프로젝트 의존성만으로 관리할 수 있다.
• 메모리에서 실행되기 때문에 애플리케이션을 재시작할 때마다 초기화된다. ➜ 테스트 용도로 많이 사용된다.
• JPA의 테스트, 로컬 환경에서의 구동에서 사용할 예정

 

JPA 사용하기

Posts 클래스 

domain 패키지 생성

domain 패키지는 도메인을 담을 패키지다.

➜ 여기서 도메인이란 게시글, 댓글, 회원, 정산, 결제 등 소프트웨어에 대한 요구사항 혹은 문제영역이라고 생각하면 된다.

 

domain 패키지에 posts 패키지와 Posts 클래스 생성 ➜ Posts 클래스 작성

import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;

import javax.persistence.*;

@Getter
@NoArgsConstructor
@Entity
public class Posts {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(length = 500, nullable = false)
    private String title;

    @Column(columnDefinition = "TEXT", nullable = false)
    private String content;

    private String author;

    @Builder
    public Posts(String title, String content, String author) {
        this.title = title;
        this.content = content;
        this.author = author;
    }
}

주요 어노테이션을 클래스에 가깝게 둔다.

 

@Entity는 JPA의 어노테이션이고, @Getter와 @NoArgsConstructor는 Lombok의 어노테이션이다.

Lombok은 코드를 단순화시켜 주지만 필수 어노테이션은 아니다.

그래서 주요 어노테이션인 @Entity를 클래스에 가깝게 두고, 롬복 어노테이션을 그 위로 두었다.

 

이렇게 하면 코틀린 등의 새 언어 전환으로 Lombok이 더이상 필요 없을 경우 쉽게 삭제할 수 있다.

 

여기서 Posts 클래스는 실제 DB의 테이블과 매칭될 클래스이며 보통 Entity 클래스라고 한다.

JPA를 사용하면 DB 데이터에 작업할 경우 실제 쿼리를 날리기보다, 이 Entity 클래스의 수정을 통해 작업한다.

 

여기서 사용한 JPA 어노테이션을 간략히 알아보자.

 

JPA 어노테이션

@Entity

• 테이블과 링크될 클래스임을 나타낸다.
• 기본값으로 클래스의 카멜케이스 이름을 _ 으로 테이블 이름을 매칭한다.
  ex) SalesManager.java => sales_manager table

@Id

• 해당 테이블의 PK 필드를 나타낸다.

@GeneratedValue

• PK의 생성 규칙을 나타낸다.
• 스프링 부트 2.0에서는 Generation Type.IDENTITY 옵션을 추가해야한 auto_increment된다.

@Column

• 테이블의 칼럼을 나타내며 굳이 선언하지 않더라도 해당 클래스의 필드는 모두 칼럼이 된다.
• 기본값 외에 추가로 변경이 필요한 옵션이 있으면 사용한다.
• 문자열의 경우 VARCHAR(255)가 기본값인데, 사이즈를 500으로 늘리고 싶거나, 타입을 TEXT로 변경하고 싶거나 등의 경우에 사용된다.

 

Lombok 어노테이션

@NoArgsConstructor

• 기본 생성자 자동 추가
• public Posts() {}와 같은 효과

@Getter

• 클래스 내 모든 필드의 Getter 메서드를 자동생성
  ex) getName, getAddress() 등을 선언하지 않아도 호출 가능

@Builder

• 해당 클래스의 빌더 패턴 클래스를 생성
• 생성자 상단에 선언 시 생성자에 포함된 필드만 빌더에 포함

➜ Lombok의 어노테이션들은 코드 변경량을 최소화시켜 주기 때문에 자주 사용한다.

 

 

이 Posts클래스에는 Setter 메서드가 없다.

getter/setter를 무작정 생성하면 클래스의 인스턴스 값들이 언제 어디서 변해야 하는지 구분할 수 없어, 차후 기능 변경 시 복잡해진다.

그래서 Entity 클래스에서는 절대 Setter 메서드를 만들지 않는다.

대신, 해당 필드의 값 변경이 필요하면 명확히 그 목적과 의도를 나타낼 수 있는 메서드를 추가해야 한다.

 

잘못된 사용

public class Order {
	public void setStatus(boolean status) {
    	this.status = status
    }
}

public void 주문서비스의_취소이벤트() {
	order.setStatus(false);
}

올바른 사용

public class Order {
	public void cancleOrder() {
    	this.status = status
    }
}

public void 주문서비스의_취소이벤트() {
	order.cancelOrder();
}

그러면 Setter가 없는 상황에서 어떻게 값을 채워 DB에 삽입해야 할까?

 

기본적인 구조는 생성자를 통해 DB에 삽입하는 것이며, 값 변경이 필요한 경우 해당 이벤트에 맞는 public 메서드를 호출하여 변경하는 것을 전제로 한다.

 

이 책에서 생성자 대신에 @Builder를 통해 제공되는 빌더 클래스를 사용한다.

생성자나 빌더나 생성 시점에 값을 채워주는 역할은 같다.

다만, 생성자는 지금 채워야 할 필드가 무엇인지 명확히 지정할 수 없다.

예를 들어 다음과 같은 생성자가 있다면 개발자가 new Example(b, a)처럼 a와 b의 위치를 변경해도 코드를 실행하기 전까지는 문제를 찾을 수가 없다.

public Example(String a, String b) {
	this.a = a;
    this.b = b;
}

하지만 빌더를 사용하게 되면 어느 필드에 어떤 값을 채워야 할지 명확하게 인지할 수 있다.

Example.builder().a(a).b(b).build();

 

JpaRepository

그 다음 Posts 클래스로 Database를 접근하게 해줄 JpaRepository를 생성한다.

import org.springframework.data.jpa.repository.JpaRepository;

public interface PostRepository extends JpaRepository<Posts, Long> {
    
}

보통 ibatis나 Mybatis 등에서 Dao라고 불리는 DB Layer 접근자이다.

JPA에선 Repository라고 부르며 인터페이스로 생성한다.

단순히 인터페이스를 생성한 후, JpaRepository<Entity 클래스, PK 타입>를 상속하면 기본적인 CRUD 메서드가 자동으로 생성된다.

 

@Repository를 추가할 필요도 없다.

주의할 점은 Entity 클래스와 기본 Entity Repository는 함께 위치해야 한다는 점이다. (같은 패키지)

둘은 아주 밀접한 관계이고, Entity 클래스는 기본 Repository 없이는 제대로 역할을 할 수가 없다.

 

나중에 프로젝트 규모가 커져 도메인별로 프로젝트를 분리해야 한다면 도메인 패키지에서 함께 관리한다.

 

간단하게 테스트 코드로 기능을 검증해보자.

 

 

Spring Data JPA 테스트 코드 작성하기

---

test 디렉터리에 domain.posts 패키지 생성 => 테스트 클래스는 PostsRepositoryTest 생성

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit.jupiter.SpringExtension;

import java.util.List;

import static org.assertj.core.api.Assertions.assertThat;

@ExtendWith(SpringExtension.class)
@SpringBootTest
public class PostsRepositoryTest {

    @Autowired
    PostsRepository postsRepository;

    @AfterEach
    public void cleanup() {
        postsRepository.deleteAll();
    }
    
    @Test
    public void 게시글저장_불러오기() {
        //given
        String title = "테스트 게시글";
        String content = "테스트 본문";
        
        postsRepository.save(Posts.builder()
                .title(title)
                .content(content)
                .author("emaileId@gmail.com")
                .build());
        
        //when
        List<Posts> postsList = postsRepository.findAll();
        
        //then
        Posts posts = postsList.get(0);
        assertThat(posts.getTitle()).isEqualTo(title);
        assertThat(posts.getContent()).isEqualTo(content);
    }
}

@AfterEach

• JUnit에서 단위 테스트가 끝날 때마다 수행되는 메서드를 지정
• 보통은 배포 전에 전체 테스트를 수행할 때 테스트간 데이터 침범을 막기 위해 사용한다.
• 여러 테스트가 동시에 수행되면 H2에 데이터가 남아 있어 다음 테스트 실행 시 테스트가 실패할 수 있다.
  (데이터 초기화 해줘야 한다)

postsRepository.save

• 테이블 posts에 insert/update 쿼리를 실행한다.
• id 값이 있다면 update가, 없다면 insert 쿼리가 실행된다.

postsRepository.findAll

• 테이블 posts에 있는 모든 데이터를 조회해오는 메서드다.

별다른 설정 없이 @SpringBootTest를 사용할 경우 H2 데이터베이스를 자동으로 실행해 준다.

 

실제로 실행된 쿼리는 어떤 형태일까?

실행된 쿼리를 로그로 ON/OFF 할 수 있는 설정이 있다.

다만, 이런 설정들을 Java 클래스로 구현할 수 있으나 스프링 부트에서는 application.properties, application.yml 등의 파일로 한 줄의 코드로 설정할 수 있도록 지원하고 권장한다.

 

src/main/resources 디렉토리 아래에 application.properties 파일을 생성하여 아래 옵션을 추가한다.

spring.jpa.show_sql=true

그 다음 테스트를 다시 실행하면 콘솔에서 쿼리 로그를 확인할 수 있다.

create 쿼리에서 id bigint generated by default as identity라는 옵션으로 생성된 것을 볼 수 있다.

이는 H2의 쿼리 문법이 적용되었기 때문인데 H2는 MySQL의 쿼리를 수행해도 정상적으로 작동하기 때문에 이후 디버깅을 위해서 출력되는 쿼리 로그를 MySQL 버전으로 변경해 보도록 한다.

 

이 옵션도 application.properties에서 설정이 가능하다.

spring.jpa.show_sql=true
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL57Dialect
spring.jpa.properties.hibernate.dialect.storage_engine=innodb
spring.datasource.hikari.jdbc-url=jdbc:h2:mem:testdb;MODE=MYSQL
spring.datasource.hikari.username=sa

 

버전이 올라감에 따라 설정이 조금 달라졌다.

main과 test의 resource에 application.properties을 생성하여 위 코드를 추가해야 한다.

이로써 JPA와 H2에 대한 기본적인 기능과 설정을 마쳤다. 본격적으로 API를 만들도록 하자.

 

 

등록/수정/조회 API 만들기

---

API를 만들기 위해 총 3개의 클래스가 필요하다.

• Request 데이터를 받을 Dto
• API 요청을 받을 Controller
• 트랜잭션, 도메인 기능 간의 순서를 보장하는 Service

Service는 트랜잭션, 도메인 간 순서 보장의 역할만 한다.

 

비즈니스 로직은 누가 처리할까?

Spring 웹 계층

Web Layer

• 흔히 사용하는 컨트롤러(@Controller)와 JSP/Freemarker 등의 뷰 템플릿 영역이다.
• 이외에도 필터(@Filter), 인터셉터, 컨트롤러 어드바이스(@ControllerAdvice) 등
  외부 요청과 응답에 대한 전반적인 영역을 이야기한다.

Service Layer

• @Service에 사용되는 서비스 영역이다.
• 일반적으로 Controller와 Dao의 중간 영역에서 사용된다.
• @Transactional이 사용되어야 하는 영역이기도 하다.

Repository Layer

• Database와 같이 데이터 저장소에 접근하는 영역이다.

Dtos

• Dto(Data Transfer Object)는 계층 간에 데이터 교환을 위한 객체를 이야기하며
  Dtos는 이들의 영역을 얘기한다.
• 예를 들어 뷰 템플릿 엔진에서 사용될 객체나 Repository Layer에서 결과로 넘겨준 객체 등을 일컫는다.

Domain Model

• 도메인이라 불리는 개발 대상을 모든 사람이 동일한 관점에서 이해할 수 있고
  공유할 수 있도록 단순화시킨 것을 도메인모 모델이라고 한다.
• 택시 앱이라고 하면 배차, 탑승, 요금 등이 모두 도메인이 될 수 있다.
• 무조건 데이터베이스의 테이블과 관계가 있어야만 하는 것은 아니다.
  => VO처럼 값 객체들도 이 영역에 해당하기 때문이다.

Domain에서 비즈니스 처리를 담당한다.

기존에 서비스로 처리하던 방식을 트랜잭션 스크립트라고 한다. 주문 취소 로직을 작성한다면 다음과 같다.

 

Pseduo code

@Transactional
public Order cacelOrder(int orderIde) {
	1)	데이터베이스로부터 주문정보 (Orders), 결제정보(Billing),
    	배송정보(Delivery) 조회
	2)	배송 취소를 해야 하는지 확인
    3)	if (배송 중이라면) {
    		배송 취소로 변경
    	}
    4)	각 테이블에 취소 상태 Update
}

 

실제 code

@Transactional
public Order cancelOrder(int orderId) {
	OrdersDto order = ordersDao.selectOrders(orderId);
    BillingDto billing = billingDao.selectBilling(orderId);
    DeliveryDto delivery = deliveryDao.selectDelivery(orderId);
    
    String deliveryStatus = delivery.getStatus();
    
    if ("IN_PROGRESS".equals(deliveryStatus)) {
    	delivery.setStatus("CANCEL");
        deliveryDao.update(delivery);
    }
    
    order.setStatus("CANCEL");
    ordersDao.update(order);
    
    billing.setStatus("CANCEL");
    deliveryDao.update(billing);
    
    return order;
}

• 모든 로직이 서비스 클래스 내부에서 처리된다.
• 그러다 보니 서비스 계층이 무의미하며, 객체란 단순히 데이터 덩어리 역할만 하게 된다.
• 반면 도메인 모델에서 처리할 경우 다음과 같은 코드가 될 수 있다.

 

도메인 모델 code

@Transactional
public Order cancelOrder(int orderId) {
	
    Orders order = ordersRepository.findById(orderId);
    Billing billing = billingRepository.findByOrderId(orderId);
    Delivery delivery = deliveryRepository.findByOrderId(orderId);
    
    delivery.cancel();
    
    order.cancel();
    billing.cancel();
    
    return order;
}

• order, billing, delivery가 각자 본인의 취소 이벤트 처리를 하며,
  서비스 메서드는 트랜잭션과 도메인 간의 순서만 보장해 준다.

 

 

등록/수정/삭제 기능 만들기

---

등록 기능

아래의 각 패키지에 클래스를 생성한다.

• web 패키지: PostsApiController
• web.dto 패키지: PostsSaveRequestDto
• service.posts 패키지: PostsService

PostsApiController

import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;

@RequiredArgsConstructor
@RestController
public class PostsApiController {

    private final PostsService postsService;

    @PostMapping("/api/v1/posts")
    public Long save(@RequestBody PostsSaveRequestDto requestDto) {
        return postsService.save(requestDto);
    }
}

PostsService

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@RequiredArgsConstructor
@Service
public class PostsService {
    private final PostsRepository postsRepository;

    @Transactional
    public Long save(PostsSaveRequestDto requestDto) {
        return postsRepository.save(requestDto.toEntity()).getId();
    }
}

스프링에서 Bean을 주입받는 방식들은 다음과 같다.

• @Autowired
• setter
• 생성자

이 중 가장 권장하는 방식은 생성자로 주입받는 방식이다. (@Autowired는 권장하지 않는다)

생성자는 어디에 있을까?

 

@RequiredArgsConstructor에서 해결해 준다.

final이 선언된 모든 필드를 인자값으로 하는 생성자를 Lombok의 @RequiredArgsConstructor가 대신 생성해 준것이다.

 

Lombok 어노테이션을 사용한 이유는

클래스의 의존성 관계가 변경될 때마다 생성자 코드를 계속 수정하는 번거로움을 해결하기 위함이다.

Lombok 어노테이션이 있으면 해당 컨트롤러에 새로운 서비스를 추가하거나, 기존 컴포넌트를 제거하는 등의 상황이 발생해도 생성자 코드는 전혀 손대지 않아도 된다.

 

PostsSaveRequestDto

import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Getter
@NoArgsConstructor
public class PostsSaveRequestDto {

    private String title;
    private String content;
    private String author;

    @Builder
    public PostsSaveRequestDto(String title, String content, String author) {
        this.title = title;
        this.content = content;
        this.author = author;
    }

    public Posts toEntity() {
        return Posts.builder()
                .title(title)
                .content(content)
                .author(author)
                .build();
    }
}

절대 Entity 클래스를 Request/Response 클래스로 사용해서는 안 된다.

 

Entity 클래스는 데이터베이스와 맞닿은 핵심 클래스다. Entity 클래스를 기준으로 테이블이 생성되고, 스키마가 변경된다.

 

수많은 서비스 클래스나 비즈니스 로직들이 Entity 클래스를 기준으로 동작한다. Entity 클래스가 변경되면 여러 클래스에 영향을 끼치지만, Request와 Response용 Dto는 View를 위한 클래스라 변경이 자주 필요하다.

 

View Layer와 DB Layer의 역할 분리를 철저하게 하는 게 좋다.

꼭 Entity 클래스와 Controller에서 쓸 Dto는 분리해서 사용해야 한다.

 

등록 기능의 코드가 완성되었으니 테스트 코드로 검증해보자.

등록 기능 테스트

test 패키지 => web 패키지 => PostsApiControllerTest 생성하여 작성

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.web.client.TestRestTemplate;
import org.springframework.boot.web.server.LocalServerPort;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.test.context.junit.jupiter.SpringExtension;

import java.util.List;

import static org.assertj.core.api.Assertions.assertThat;

@ExtendWith(SpringExtension.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class PostsApiControllerTest {

    @LocalServerPort
    private int port;

    @Autowired
    private TestRestTemplate restTemplate;

    @Autowired
    private PostsRepository postsRepository;

    @AfterEach
    public void tearDown() throws Exception {
        postsRepository.deleteAll();
    }

    @Test
    public void Posts_등록된다() throws Exception {
        //given
        String title = "title";
        String content = "content";
        PostsSaveRequestDto requestDto = PostsSaveRequestDto.builder()
                .title(title)
                .content(content)
                .author("author")
                .build();

        String url = "http://localhost:" + port + "/api/v1/posts";

        //when
        ResponseEntity<Long> responseEntity = restTemplate.
                postForEntity(url, requestDto, Long.class);

        //then
        assertThat(responseEntity.getStatusCode()).isEqualTo(HttpStatus.OK);
        assertThat(responseEntity.getBody()).isGreaterThan(0L);

        List<Posts> all = postsRepository.findAll();
        assertThat(all.get(0).getTitle()).isEqualTo(title);
        assertThat(all.get(0).getContent()).isEqualTo(content);
    }
}

@WebMvcTest는 외부 연동과 관련된 부분만 활성화되고 JPA의 기능은 작동하지 않는다.

JPA 기능까지 한번에 테스트할 때는 @SpringBootTest와 TestRestTemplate를 사용하면 된다.

랜덤 포트 실행과 insert 쿼리가 정상적으로 실행되는 것을 확인할 수 있다.

 

수정/조회 기능

PostsApiController

import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.*;

@RequiredArgsConstructor
@RestController
public class PostsApiController {

    private final PostsService postsService;

    @PostMapping("/api/v1/posts") // 등록
    public Long save(@RequestBody PostsSaveRequestDto requestDto) {
        return postsService.save(requestDto);
    }

    @PutMapping("/api/v1/posts/{id}") // 수정
    public Long update(@PathVariable Long id, @RequestBody PostsUpdateRequestDto requestDto) {
        return postsService.update(id, requestDto);
    }

    @GetMapping("/api/v1/posts/{id}") // 조회
    public PostsResponseDto findById(@PathVariable Long id) {
        return postsService.findById(id);
    }
}

PostsResponseDto

@Getter
public class PostsResponseDto {

    private Long id;
    private String title;
    private String content;
    private String author;

    public PostsResponseDto(Posts entity) {
        this.id = entity.getId();
        this.title = entity.getTitle();
        this.content = entity.getContent();
        this.author = entity.getAuthor();
    }
}

 

PostsUpdateRequestDto

import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Getter
@NoArgsConstructor
public class PostsUpdateRequestDto {
    private String title;
    private String content;

    @Builder
    public PostsUpdateRequestDto(String title, String content) {
        this.title = title;
        this.content = content;
    }
}

Posts

import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;

import javax.persistence.*;

@Getter
@NoArgsConstructor
@Entity
public class Posts {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(length = 500, nullable = false)
    private String title;

    @Column(columnDefinition = "TEXT", nullable = false)
    private String content;

    private String author;

    @Builder
    public Posts(String title, String content, String author) {
        this.title = title;
        this.content = content;
        this.author = author;
    }

    public void update(String title, String content) {
        this.title = title;
        this.content = content;
    }
}

PostsService

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@RequiredArgsConstructor
@Service
public class PostsService {
    private final PostsRepository postsRepository;

    /*
    @Transactional 어노테이션 => 트랜잭션 처리 지원
    트랜잭션의 개념
    모든 작업들이 성공적으로 완료되어야 작업 묶음의 결과를 적용하고, 어떤 작업에서 오류가 발생했을 때는
    이전에 있던 모든 작업들이 성공적이었더라도 없었던 일처럼 완전히 되돌리는 것

    데이터베이스를 다룰 때 트랜잭션을 적용하면 데이터 추가, 갱신, 삭제 등으로 이루어진 작업을 처리하던 중
    오류가 발생했을 때 모든 작업들을 원상태로 되돌릴 수 있다.

    일련의 작업들을 묶어서 하나의 단위로 처리하고 싶을 때 사용용
    */
    @Transactional
    public Long save(PostsSaveRequestDto requestDto) {
        return postsRepository.save(requestDto.toEntity()).getId();
    }

    @Transactional
    public Long update(Long id, PostsUpdateRequestDto requestDto) {
        Posts posts = postsRepository.findById(id)
                .orElseThrow(()-> new
                        IllegalArgumentException("해당 게시글이 없습니다. id = " + id));
        posts.update(requestDto.getTitle(), requestDto.getContent());
        return id;
    }

    public PostsResponseDto findById(Long id) {
        Posts entity = postsRepository.findById(id)
                .orElseThrow(()-> new
                        IllegalArgumentException("해당 게시글이 없습니다. id = " + id));
        return new PostsResponseDto(entity);

    }
}

 

update 기능에서 데이터베이스 쿼리를 날리는 부분이 없다.

이것이 가능한 이유는 JPA의 영속성 컨텍스트 때문이다.

 

영속성 컨텍스트란, 엔티티를 영구 저장하는 환경이다.

JPA의 핵심 내용은 엔티티가 영속성 컨텍스트에 포함되어 있냐 아니냐로 갈린다.

 

JPA의 엔티티 매니저가 활성화된 상태로 트랜잭션 안에서 데이터베이스에서 데이터를 가져오면 이 데이터는 영속성 컨텍스트가 유지된 상태이다.

 

이 상태에서 해당 데이터의 값을 변경하면 트랜잭션이 끝나는 시점에 해당 테이블에 변경분을 반영한다.

즉, Entity 객체의 값만 변경하면 별도로 Update 쿼리를 날릴 필요가 없다. 이 개념을 더티 체킹이라고 한다.

 

수정 기능 테스트

PostsApiControllerTest

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.web.client.TestRestTemplate;
import org.springframework.boot.web.server.LocalServerPort;
import org.springframework.http.HttpEntity;
import org.springframework.http.HttpMethod;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.test.context.junit.jupiter.SpringExtension;

import java.util.List;

import static org.assertj.core.api.Assertions.assertThat;

@ExtendWith(SpringExtension.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class PostsApiControllerTest {

    @LocalServerPort
    private int port;

    @Autowired
    private TestRestTemplate restTemplate;

    @Autowired
    private PostsRepository postsRepository;

    @AfterEach
    public void tearDown() throws Exception {
        postsRepository.deleteAll();
    }

    @Test
    public void Posts_등록된다() throws Exception {
        //given
        String title = "title";
        String content = "content";
        PostsSaveRequestDto requestDto = PostsSaveRequestDto.builder()
                .title(title)
                .content(content)
                .author("author")
                .build();

        String url = "http://localhost:" + port + "/api/v1/posts";

        //when
        ResponseEntity<Long> responseEntity = restTemplate.
                postForEntity(url, requestDto, Long.class);

        //then
        assertThat(responseEntity.getStatusCode()).isEqualTo(HttpStatus.OK);
        assertThat(responseEntity.getBody()).isGreaterThan(0L);

        List<Posts> all = postsRepository.findAll();
        assertThat(all.get(0).getTitle()).isEqualTo(title);
        assertThat(all.get(0).getContent()).isEqualTo(content);
    }

    @Test
    public void Posts_수정된다() throws Exception {
        //given
        Posts savedPosts = postsRepository.save(Posts.builder()
                .title("title")
                .content("content")
                .author("author")
                .build());

        Long updateId = savedPosts.getId();
        String expectedTitle = "title2";
        String expectedContent = "content2";

        PostsUpdateRequestDto requestDto = PostsUpdateRequestDto.builder()
                .title(expectedTitle)
                .content(expectedContent)
                .build();

        String url = "http://localhost:" + port + "/api/v1/posts/" + updateId;

        HttpEntity<PostsUpdateRequestDto> requestEntity = new HttpEntity<>(requestDto);

        //when
        ResponseEntity<Long> responseEntity =
                restTemplate.exchange(url, HttpMethod.PUT,requestEntity, Long.class);

        //then
        assertThat(responseEntity.getStatusCode()).isEqualTo(HttpStatus.OK);
        assertThat(responseEntity.getBody()).isGreaterThan(0L);

        List<Posts> all = postsRepository.findAll();
        assertThat(all.get(0).getTitle()).isEqualTo(expectedTitle);
        assertThat(all.get(0).getContent()).isEqualTo(expectedContent);

    }
}

update 테스트 결과

 

조회 기능 테스트

톰캣을 실행해서 H2 데이터베이스를 사용하여 테스트해본다.

 

로컬 환경에서 실행하기 때문에 직접 접근하려면 웹 콘솔을 사용해야 한다.

웹 콘솔 옵션을 활성화 하기 위해 application.properties에 다음과 같이 옵션을 추가한다.

spring.h2.console.enabled=true

그 다음 메인 메서드를 하여 localhost:8080/h2-console로 접속하면 다음과 같이 웹 콘솔 화면이 나타난다.

Connect를 누르면 POSTS 테이블이 정상적으로 보여야 한다.

데이터가 없으니 간단한 insert 쿼리를 실행하고 API로 조회해본다.

insert into posts(author, content, title) values ('author', 'content', 'title');

정상적으로 등록됨

json으로 확인

 

 

JPA Auditing으로 생성시간/수정시간 자동화하기

---

보통 엔티티에는 유지보수에 중요한 데이터의 생성시간과 수정시간을 포함한다.

그렇다 보니 매번 DB에 삽입하기 전, 갱신하기 전에 날짜 데이터를 등록/수정하는 코드가 여러번 들어간다.

// 생성일 추가 코드 예제
public void savePosts() {
	...
	posts.setCreateDate(new LocalDate());
    postsRepository.save(posts);
    ...
}

이런 반복적인 코드를 모든 테이블과 서비스 메서드에 포함하지 않도록 JPA Auditing을 사용해보자.

 

LocalDate 사용

domain 패키지 => BaseTimeEntity 클래스 생성

package com.seunggyu.book.springboot.domain;

import lombok.Getter;
import org.springframework.data.annotation.CreatedDate;
import org.springframework.data.annotation.LastModifiedDate;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

import javax.persistence.EntityListeners;
import javax.persistence.MappedSuperclass;
import java.time.LocalDateTime;

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public class BaseTimeEntity {
    
    @CreatedDate
    private LocalDateTime createdDate;
    
    @LastModifiedDate
    private LocalDateTime modifiedDate;
}

이 클래스는 모든 Entity의 상위 클래스가 되어 Entity들의 생성시간, 변경시간을 자동으로 관리하는 역할을 한다.

 

@MappedSuperclass

• JPA Entity 클래스들이 BaseTimeEntity을 상속할 경우 필드들도 칼럼으로 인식하도록 한다.

@EntityListeners(AuditingEntityListener.class)

• BaseTimeEntity 클래스에 Auditing 기능을 포함시킨다.

@CreatedDate

• Entity가 생성되어 저장될 때 시간이 자동 저장된다.

@LastModifiedDate

• 조회한 Entity의 값을 변경할 때 시간이 자동 저장된다.

 

Posts 클래스가 BaseTimeEntity를 상속받도록 변경한다.

public class Posts extends BaseTimeEntity { ... }

JPA  Auditing 어노테이션들을 모두 활성화할 수 있도록 Application 클래스에 활성화 어노테이션 하나를 추가한다.

@EnableJpaAuditing
@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

 

JPA Auditing 테스트 코드 작성하기

PostsRepositoryTest 클래스에서 테스트 메서드 추가

@Test
public void BaseTimeEntity_등록() {
    //given
    LocalDateTime now = LocalDateTime.of(2022,7,13,0,0,0);
    postsRepository.save(Posts.builder()
            .title("title")
            .content("content")
            .author("author")
            .build());

    //when
    List<Posts> postsList = postsRepository.findAll();

    //then
    Posts posts = postsList.get(0);

    System.out.println(">>>>>> createDate = " + posts.getCreatedDate()
            +", modifiedDate = " + posts.getModifiedDate());
    assertThat(posts.getCreatedDate()).isAfter(now);
    assertThat(posts.getModifiedDate()).isAfter(now);
}

테스트 결과

BaseTimeEntity만 상속받으면 등록일/수정일을 반복적으로 작성할 필요없다.