요구사항 분석   

 

 진행할 웹 애플리케이션의 요구사항은 다음과 같다. 

 

 


 

    프로젝트에 Spring Data JPA 적용하기   

 

 먼저, build.gradle에 의존성을 추가로 등록해야 한다. 

 

dependencies {
    //compile('org.springframework.boot:spring-boot-starter-web')
    //compile('org.projectlombok:lombok')
    compile('org.springframework.boot:spring-boot-starter-data-jpa')
    compile('com.h2database:h2')
    //testCompile('org.springframework.boot:spring-boot-starter-test')
}

 

 

1. spring-boot-start-data-jpa

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

2. h2

  • 인메모리 관계형 데이터베이스로 별도의 설치 없이 프로젝트 의존성으로만 관리할 수 있다.
  • 메모리에서 실행되기 때문에 애플리케이션을 재시작할 때마다 초기화된다. 보통 테스트 용도로 많이 사용한다.

 

 

 build.gradle에 의존성을 추가했다면 domain 패키지를 하나 추가한다. 이 패키지는 게시글, 댓글, 회원 등 각각의 요구사항인 도메인을 담을 패키지이다. 그 후에 posts 패키지와 Posts 클래스를 만든다. 그리고 다음 코드를 추가한다.

 

 

package com.daldalhada.springboot.domain.posts;

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

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@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;
    }
}

 

 Posts 클래스는 실제 DB의 테이블과 매칭될 클래스이며 Entity 클래스라고도 한다. RDB와 달리, JPA에서는 쿼리를 날리기보다는 Entity 클래스의 수정을 통해 이루어진다. 

 

 

1. @Entity

  • 테이블과 매칭될 클래스이며 기본값으로 클래스의 카멜케이스 이름을 언더스코어()_로 테이블 이름을 매칭한다. 
  • UsersManager.java ▶ Users_manager table

2. @Id

  • 해당 테이블의 기본키(PK) 필드를 나타낸다.
  • 웬만하면 Long(RDB에서 BigInt) 타입의 auto_increment를 추천한다.

3. @GeneratedValue

  • 기본키의 생성 규칙을 나타낸다.
  • [참고] 스프링부트 2.0에서는 GenerationType.IDENTITY 옵션을 추가해야 auto_increment 옵션을 사용할 수 있다.

4. @Column

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

 

5. @NoArgsConstructor

  • 기본 생성자를 자동으로 추가해준다.(public Posts() { } 와 같은 효과)

6. @Getter

  • 클래스 내 모든 필드의 Getter 메소드를 자동으로 생성해준다.

7. @Builder

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

 

 서비스 초기 구축 단계에선 테이블 설계(여기서는 Entity)가 빈번하게 변경되는데 5~7번에 해당하는 롬복 어노테이션은 코드 변경량을 최소화시켜 주기에 적극적으로 사용하는 것이 좋다.

 

 


 

    데이터베이스에 값을 추가하는 방법   

 

 위의 Posts 클래스는 Getter 메소드는 설정했지만 Setter 메소드가 없다. Entity 클래스에서는 절대로 Setter 메소드를 만들지 않아야 하는 이유가 있는데, 해당 클래스의 인스턴스 값들이 언제 어디서 변해야 하는지 코드상으로 명확하게 구분할 수 없기 때문이다. 따라서, 해당 필드 값 변경이 필요하면 그 목적과 의도를 나타낼 수 있는 메소드를 추가해야만 한다. 

 

 주문 취소 메소드를 예로 들면

 

// 잘못된 사용 예

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

public void cancel(){
	order.setstatus(false);
}
// 올바른 사용 예

public class Order{
	public void orderCancel(){
    		this.status = false;
    }
}

public void cancel(){
	order.orderCalncel();
}

 

 

 그러면 Setter가 없는 상황에서 값을 데이터베이스에 어떻게 삽입(Insert)해야 할까? 기본적인 구조는 생성자를 통해 값을 채운 후 DB에 삽입하고 값 변경이 필요하면 정의한 public 메소드를 호출하여 변경한다. 

 

 여기서는 생성자 대신에 @Builder를 통해 제공되는 빌더 클래스를 이용한다. 생성자나 빌더나 생성 시점에 값을 채워주는 역할은 똑같지만 생성자의 경우에는 지금 채워야 할 필드가 무엇인지 명확히 지정할 수 없다. 

 

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

 

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

 

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

 

User.builder()
    .a(a)
    .b(b)
    .c(c)
    .build();

 

 Posts 클래스 생성이 끝났으면 Posts 클래스로 데이터베이스에 접근하게 해줄 JPARepository를 생성한다. 보통 MyBatis 등에서 DAO라고 불리는 DB Layer 접근자이다. JPA에선 Repository라고 불리며 인터페이스로 생성한다. 인터페이스 생성 후 JpaRepository<Entity Class, PK Type>를 상속하면 기본적인 CRUD 메소드가 자동으로 생성된다. 

 

 주의할점은 Entity 클래스와 Repository는 같은 폴더 위치에 있어야 한다는 점이다. 다른 위치에 있다면 제대로 수행할 수가 없다. 

 

 

package com.daldalhada.springboot.domain.posts;

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

public interface PostRepository extends JpaRepository<Posts, Long> {

}

 


    테스트 코드 작성하기   

 

 위의 작성된 코드들을 테스트 코드로 기능을 검증해봐야 하므로 test 디렉토리에 domain.posts 패키지를 생성하고, 테스트 클래스는 PostsRepositoryTest란 이름으로 생성하고 다음과 같은 코드를 추가한다. 

 

package com.daldalhada.springboot.domain.posts;

import org.junit.After;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;

import java.util.List;

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

@RunWith(SpringRunner.class)
@SpringBootTest
public class PostsRepositoryTest {
    @Autowired
    PostsRepository postsRepository;

    @After
    public void cleanup() {
        postsRepository.deleteAll();
    }

    @Test
    public void get_board() {
        //given
        String title = "테스트 게시글";
        String content = "테스트 본문";

        postsRepository.save(Posts.builder()
                .title(title)
                .content(content)
                .author("jojoldu@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);
    }
}

 

1. @After

  • JUnit에서 단위 테스트가 끝날 때마다 수행되는 메소드를 지정한다. 
  • 보통 배포 전 전체 테스트를 수행할 때 테스트 간 데이터 침범을 막기 위해 사용한다. (여러 테스트가 동시에 실행되면 데이터베이스에 데이터가 그대로 남아 있을 수 있어 다음 테스트가 실패할 수 있으므로 보통 delete 해준다.)

2. postRepository.save

  • 위에서 인터페이스에 CRUD 메소드가 저절로 생성되었다고 하였는데, save는 테이블에 insert/update 쿼리를 실행한다.
  • id가 있으면 update가 id가 없으면 insert 쿼리가 실행된다.

3. postRepository.findAll

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

4. @SpringBootTest

  • 별다른 설정 없이 H2 데이터베이스를 자동으로 샐행해준다.

 

 

 [참고] 흔히 할 수 있는 실수로 인터페이스명의 이름이 다른 경우 인식을 하지 못하므로 조심해야 한다. 필자는 Posts에서 's'가 없었다.

 

 

 

 테스트 코드를 실행해보면 테스트가 통과되는 것을 확인할 수 있다.

 

 

 

 그런데, 실제로 실행된 쿼리는 어떤 형태일지 궁금할 수 있다. 실행된 쿼리를 로그로 확인할 수 있는데 Java 클래스로 구현하거나 appication.properties 파일의 코드 수정으로 가능하다. 저번에 생성했던 resources 폴더의 application.properties로 들어가 다음 코드를 추가해준다. 

 

spring.jpa.show_sql=true

 

 

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

 

 

 

 만약 출력되는 쿼리 로그를 MySQL 버전으로 변경해보고 싶다면 appication.properties에서 다음 코드를 추가해준다. 

spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5InnoDBDialect

 

 

 잘 적용되었음을 확인할 수 있다.

'스프링 부트 프로젝트 > 데이터베이스 다루기' 카테고리의 다른 글

7. API 만들기  (0) 2020.11.19
5. JPA  (0) 2020.10.07

 

    스프링부트에서 데이터베이스 다루기   

 

 스프링부트에서 데이터베이스를 다루는 방법에는 MyBatis와 같은 SQL 매퍼(SQL Mapper)를 이용해서 데이터베이스 쿼리를 작성하는 방법과 JPA와 같은 자바 표준 ORM(Object Relational Mapping)을 이용해서 객체지향적으로 프로그래밍 하는 방법이 있다. ORM은 객체를 매핑하는 것이고, SQL 매퍼는 쿼리를 매핑하는 것이다. 

 


 

    관계형 데이터베이스와 JPA   

 

 웹 애플리케이션을 개발하다보면 Oracle, MySQL과 같은 관계형 데이터베이스(Relational Database, RDB)를 많이 사용한다. 그러다 보니 객체를 관계형 데이터베이스에서 관리하는 것이 중요하다.

 

 관계형 데이터베이스가 웹 서비스의 중심이 되면 모든 코드는 SQL 중심으로 돌아간다. 즉, 애플리케이션 코드보다 SQL 코드가 더 많아진다는 것이다. 이는 관계형 데이터베이스가 SQL을 통해서만 인식하기에 각 테이블마다 기본적인 CRUD(Create, Read, Update, Delete) SQL을 매번 생성해야 한다. 핵심은 관계형 데이터베이스를 사용해야만 하는 상황에서는 매번 생성해야 하는 SQL을 피할 수 없다는 것이다. 

 

 이러한 SQL은 두 가지 문제점이 있는데 첫 번째는 위에서 설명한 CRUD SQL의 반복적인 작업을 해야하는 것이고 두 번째는 패러다임 불일치 문제이다. 패러다임 불일치 문제는 관계형 데이터베이스와 객체지향 프로그래밍 언어의 패러다임이 서로 다르다는 점에서 발생한다. 

 

 관계형 데이터베이스는 어떻게 데이터를 저장할지에 초점을 맞추는데 반해 객체지향 프로그래밍 언어는 기능과 속성을 한 곳에서 관리한다. 

 

 아래 코드는 객체지향 프로그래밍에서 부모가 되는 객체를 가져오는 방법이다. 

 

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

 

 여기서는 User와 Group의 관계가 부모-자식 관계임을 알 수 있다. group은 User가 속한 Group을 가져온 코드라고 알 수 있기 때문이다. 하지만, 여기서 관계형 데이터베이스가 추가된다면 다음과 같다.

 

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

 

 여기서는 User와 Group을 따로 조회하기 때문에 User와 Group이 상속, 1:N 등 어떤 관계인지 알 수가 없다. 따라서, 다양한 객체 모델링을 데이터베이스로는 구현할 수 없다는 것이다. 

 

 JPA는 이러한 문제점을 해결하기 위해 등장했는데, 서로 다른 패러다임을 일치시켜주는 역할을 한다. 즉, 객체지향적으로 프로그래밍을 하면서 관계형 데이터베이스에 맞게 SQL을 대신 생성해서 실행해주는 역할을 한다. 객체 중심으로 개발을 하게 되면 생산성이 향상되고 유지 보수하기가 쉬워진다. 

 


 

    Spring Data JPA   

 

  JPA(Java Persistence API)는 인터페이스이면서 자바 표준 명세서이다. JPA를 사용하기 위해서는 Hibernate, Eclipse Link와 같은 구현체가 필요하다. 하지만 Spring에서는 JPA를 사용할 때 이 구현체를 직접 다루진 않는다. 

 

 구현체들을 좀 더 쉽게 사용하고자 추상시Spring Data JPA라는 모듈을 이용하여 다룬다. 이들의 관계는 다음과 같다.

 

 

 

  • 구현체 교체의 용이: Hibernate 외에 다른 구현체로 쉽게 교체하기 위함. 트렌드가 바뀌어 새로운 JPA 구현체가 떠오를 때, Spring Data JPA를 쓴다면 아주 쉽게 교체할 수 있다. 이는 Spring Data JPA 내부에서 구현체 매핑을 지원해주기 때문이다.
  • 저장소 교체의 용이: 관계형 데이터베이스 외에 다른 저장소로 쉽게 교체하기 위함. 초기에는 트래픽이 적어 모든 기능을 관계형 데이터베이스로 처리했지만 트래픽이 점점 많아져 감당이 안될 때 NoSQL로 교체가 필요하다. Spring Data JPA를 사용하면 의존성 교체만 해주면 된다. 이는 Spring Data의 하위 프로젝트들은 기본적인 CRUD의 인터페이스가 같기 때문에 가능하다. Spring Data JPA, Spring Data MongoDB, Spring Data Redis 등 하위 프로젝트들은 save(), findAll() 등을 인터페이스로 갖고 있다. 

 

  이러한 용이성들 때문에 Spring 팀에서도 Spring Data 프로젝트를 권장하고 있다. 하지만, 실무에서 JPA를 잘 사용하지 않은 이유는 높은 러닝 커브를 들 수 있다. 객체지향 프로그래밍과 데이터베이스를 둘 다 이해해야 하기 때문이다. 하지만 그만큼 JAP를 사용해서 얻는 보상이 크기 때문에 많이 바뀌고 있는 추세이다.