[스프링 DB 2편] #2. 데이터 접근 기술 - 시작

[newh08]

다양한 데이터 접근 기술에 대해 알아볼 예정.

1. 데이터 접근 기술 진행 방식 소개
2. 프로젝트 설정과 메모리 저장소
3. 프로젝트 구조 설명1 - 기본
4. 프로젝트 구조 설명2 - 설정
5. 프로젝트 구조 설명3 - 테스트
6. 데이터베이스 테이블 생성

데이터 접근 기술 진행 방식 소개

• JdbcTemplate
• MyBatis
• JPA, Hibernate
• 스프링 데이터 JPA
• Querydsl
  에 대해 학습할 예정.

이 기술들은 크게 2가지로 분류 가능

1. SQLMapper

• JdbcTemplate
• MyBatis

2. ORM 관련 기술

• JPA, Hibernate (JPA 의 구현체)
• 스프링 데이터 JPA
• Querydsl

SQLMapper의 주요 기능

• SQL 작성시 결과를 객체로 편리하게 매핑해줌
• JDBC 사용시 발생하는 중복 제거(JDBCTemplate), 각종 편리기능 제공

ORM 주요 기능

• SQL 을 작성하지 않아도 기본적인 SQL 은 대신 작성하고 처리해줌. 저장하려는 객체를 마치 자바 컬렉션에 넣듯이 저장하고, 조회하듯이 꺼내면 ORM 기술이 데이터베이스에 해당 객체를 저장하고 조회함.
• JPA 는 자바의 ORM 표준.
• 스프링 데이터 JPA, Querydsl 은 JPA 를 편리하게 사용하도록 도와주는 프로젝트.

위 데이터 저장 기술은 하나하나 내용이 방대해, 하나하나 설명하기 보단,
왜 필요한지, 장단점이 무엇인지 설명할 예정.

강의의 목표

• 데이터 접근 기술에 대한 기본 이해와 전체 큰 그림
• 각 기술들의 핵심 기능 학습
• 각 기술들을 점진적으로 도입해보고, 그 과정을 통해 특징과 장단점

처음엔 메모리로 프로젝트 만들고,
JdbcTemplate
MyBatis
JPA
스프링 데이터 JPA
Querydsl
를 점진적으로 도입해보자.

프로젝트 설정과 메모리 저장소

다양한 데이터 접근 기술을 리포지토리를 바꿔가며 하나씩 적용해볼 예정.
스프링MVC 1편에서 마지막에 완성한 프로젝트

• 단순 메모리에 상품 데이터를 저장했음
• 여기에 메모리가 아닌 데이터 접근 기술을 사용해볼 예정.

강의 코드 다운받아 itemservice-db-start 프로젝트 열자.
열어보고 각 기능들이 작동하는지 보자.
다음시간부턴 프로젝트 구조에 대한 설명.

프로젝트 구조 설명1 - 기본

build.gradle
특별한건 없고, 데이터 저장 관련 기술은 하나도 사용하지 않음. 메모리 디비 사용하기 떄문.

분석할 때는 도메인 먼저 분석을 해야함.

public class Item {

    private Long id;

    private String itemName;
    private Integer price;
    private Integer quantity;

아이템에 해당하는 리포지토리
인터페이스로 만들었고, 향후에 이를 다른 구현체로 바꿀 예정.

public interface ItemRepository { //

    Item save(Item item);

    void update(Long itemId, ItemUpdateDto updateParam);
    // 해당 아이디의 아이템을, Dto 처럼 업데이트 해라

    Optional<Item> findById(Long id);

    List<Item> findAll(ItemSearchCond cond);
    // 파라미터로 검색 조건이 넘어감. 특정 조건에 맞는 리스트를 뿌려주기 위함?

}

검색 조건
상품명은 일부만 포함되어도 검색 가능하도록 할 예정.

public class ItemSearchCond { 
    private String itemName;
    private Integer maxPrice;

• cond -> condition 의 약자. 어떤 단어를 쓰는지는 중요한게 아니고, 프로젝트에서 일관성 있게 단어를 사용하는게 중요.

업데이트를 위한 Dto
단순히 데이터를 전달하는 용도로 사용되어 Dto 가 뒤에 붙음.

@Data
public class ItemUpdateDto {
    private String itemName;
    private Integer price;
    private Integer quantity;

DTO(data transfer object)**

• 데이터 전송 객체
• DTO는 기능은 없고 데이터를 전달만 하는 용도로 사용되는 객체를 뜻한다.
  • 참고로 DTO에 기능이 있으면 안되는가? 그것은 아니다. 객체의 주 목적이 데이터를 전송하는 것이라면 DTO라 할 수 있다.
• 객체 이름에 DTO를 꼭 붙여야 하는 것은 아니다. 대신 붙여두면 용도를 알 수 있다는 장점은 있다.
• 이전에 설명한 ItemSearchCond 도 DTO 역할을 하지만, 이 프로젝트에서 Cond 는 검색 조건으로 사용한다 는 규칙을 정했다. 따라서 DTO를 붙이지 않아도 된다. ItemSearchCondDto 이렇게 하면 너무 복잡해진다. 그리고 Cond 라는것만봐도용도를알수있다.
• 참고로 이런 규칙은 정해진 것이 없기 때문에 해당 프로젝트 안에서 일관성 있게 규칙을 정하면 된다.

리포지토리 구현체

@Repository
public class MemoryItemRepository implements ItemRepository {

    private static final Map<Long, Item> store = new HashMap<>(); //static
    private static long sequence = 0L; //static

    @Override
    public Item save(Item item) { // 저장할 때 ID 는 넘어오지 않고 다른 3개 정보만 넘어옴
        item.setId(++sequence); // 저장시 시퀀스 증가
        store.put(item.getId(), item);
        return item;
    }

    @Override
    public void update(Long itemId, ItemUpdateDto updateParam) {
        Item findItem = findById(itemId).orElseThrow();
        // 메모리 데이터 이므로 참조하고 있는 값을 set으로 변경하면 실제 컬렉션 안에 있는 객체가 변경됨.
        findItem.setItemName(updateParam.getItemName());
        findItem.setPrice(updateParam.getPrice());
        findItem.setQuantity(updateParam.getQuantity());
        // 다시 save 할 필요가 없음!
    }

    @Override
    public Optional<Item> findById(Long id) { // 값이 없을수도 있기 때문에 Optional 로 반환. 
        return Optional.ofNullable(store.get(id));
    }

    @Override
    public List<Item> findAll(ItemSearchCond cond) {
        String itemName = cond.getItemName();
        Integer maxPrice = cond.getMaxPrice();
        return store.values().stream()
                .filter(item -> {
                    if (ObjectUtils.isEmpty(itemName)) { // 검색조건이 없으므로 무조건 통과
                        return true;
                    }
                    return item.getItemName().contains(itemName); // 조건 있으면 포함할때만 통과
                }).filter(item -> {
                    if (maxPrice == null) {
                        return true;
                    }
                    return item.getPrice() <= maxPrice;
                })
                .collect(Collectors.toList());
    }

    public void clearStore() { // 테스트용 메서드
        store.clear();
    }
}

• ItemRepository 인터페이스를 구현한 메모리 저장소이다.
• 메모리이기 때문에 자바를 다시 실행하면 기존에 저장된 데이터가 모두 사라진다.
• save , update , findById 는 쉽게 이해할 수 있을 것이다. 참고로 findById 는 Optional 을 반환해야하기 때문에 Optional.ofNullable 을 사용했다.
• findAll 은 ItemSearchCond 이라는 검색 조건을 받아서 내부에서 데이터를 검색하는 기능을 한다. 데이터베이스로 보면 where 구문을 사용해서 필요한 데이터를 필터링 하는 과정을 거치는 것이다.
  • 여기서 자바 스트림을 사용한다.
  • itemName 이나, maxPrice 가 null 이거나 비었으면 해당 조건을 무시한다.
  • itemName 이나, maxPrice 에 값이 있을 때만 해당 조건으로 필터링 기능을 수행한다.
• clearStore() 메모리에 저장된 Item 을 모두 삭제해서 초기화한다. 테스트 용도로만 사용한다.

서비스 코드
인터페이스
서비스를 인터페이스로 구현하는 경우는 많지 않음. 비즈니스 로직이 있기 떄문에. 로직을 수정하지 DI 로 바꾸는 경우는 거의 없음.
예제 설명을 위해 인터페이스 도입함.

public interface ItemService {

    Item save(Item item);

    void update(Long itemId, ItemUpdateDto updateParam);

    Optional<Item> findById(Long id);

    List<Item> findItems(ItemSearchCond itemSearch);
}

구현체 -> 리포지토리에 위임.

public class ItemServiceV1 implements ItemService {

    private final ItemRepository itemRepository;

    @Override
    public Item save(Item item) {
        return itemRepository.save(item);
    }

    @Override
    public void update(Long itemId, ItemUpdateDto updateParam) {
        itemRepository.update(itemId, updateParam);
    }

    @Override
    public Optional<Item> findById(Long id) {
        return itemRepository.findById(id);
    }

    @Override
    public List<Item> findItems(ItemSearchCond cond) {
        return itemRepository.findAll(cond);
    }
}

컨트롤러

public class HomeController {

    @RequestMapping("/")
    public String home() {
        return "redirect:/items";
    }
}

및 각종 화면 컨트롤러 있는데, MVC 강의에서 전부 다뤄본 것이므로 따로 설명 X

DTO 의 위치
따로 패키지를 둔다? OK
Service 에서 사용하는 ItemUpdateDto 를 Service 패키지에 두는것이 맞을까? 는 좀아니다.
서비스가 리포지토리를 호출하고, 결국 Dto의 최종 의존관계는 리포지토리에 있기 때문.
만약 서비스에서 사용하고 더이상 리포지토리로 넘기지 않는 Dto -> 서비스 패키지에 두는것이 맞음.

어디에 놔야해요?
서비스 전체 흐름
컨트롤러 -> 서비스 -> 리포지토리
인데 그럼 Dto 를 마지막까지 사용? 하는곳이 어디냐? 그곳에 두면 된다.

프로젝트 구조 설명2 - 설정

컨피그
빈을 수동으로등록

public class MemoryConfig {

    @Bean
    public ItemService itemService() {
        return new ItemServiceV1(itemRepository());
    }

    @Bean
    public ItemRepository itemRepository() {
        return new MemoryItemRepository();
    }
}

• ItemServiceV1 , MemoryItemRepository 를 스프링 빈으로 등록하고 생성자를 통해 의존관계를 주입한 다.
• 참고로 여기서는 서비스와 리포지토리는 구현체를 편리하게 변경하기 위해, 이렇게 수동으로 빈을 등록했다.
• 컨트롤러는 컴포넌트 스캔을 사용한다.

지금 서버를 띄우면 데이터가 들어가있는데, 아래 코드 때문
자동으로 호출해서 데이터 자동으로 넣어줌.

@Slf4j
@RequiredArgsConstructor
public class TestDataInit { 

    private final ItemRepository itemRepository;

    /**
     * 확인용 초기 데이터 추가
     */
    @EventListener(ApplicationReadyEvent.class)
    public void initData() {
        log.info("test data init");
        itemRepository.save(new Item("itemA", 10000, 10));
        itemRepository.save(new Item("itemB", 20000, 20));
    }
}

• 애플리케이션을 실행할 때 초기 데이터를 저장한다.
• 리스트에서 데이터가 잘 나오는지 편리하게 확인할 용도로 사용한다.
  • 이 기능이 없으면 서버를 실행할 때 마다 데이터를 입력해야 리스트에 나타난다. (메모리여서 서버를 내리면 데이터가 제거된다.)
• @EventListener(ApplicationReadyEvent.class) : 스프링 컨테이너가 완전히 초기화를 다 끝내고, 실행 준비가 되었을 때 발생하는 이벤트이다. 스프링이 이 시점에 해당 애노테이션이 붙은 initData() 메서드 를 호출해준다.
  • 참고로 이 기능 대신 @PostConstruct 를 사용할 경우 AOP 같은 부분이 아직 다 처리되지 않은 시점에 호출될 수 있기 때문에, 간혹 문제가 발생할 수 있다. 예를 들어서 @Transactional 과 관련된 AOP가 적 용되지 않은 상태로 호출될 수 있다.
  • @EventListener(ApplicationReadyEvent.class) 는 AOP를 포함한 스프링 컨테이너가 완전 히 초기화 된 이후에 호출되기 때문에 이런 문제가 발생하지 않는다.

이것도 빈으로 등록되어야 작동하는데, Application 에서 등록함

@Import(MemoryConfig.class)
@SpringBootApplication(scanBasePackages = "hello.itemservice.web")
public class ItemServiceApplication {

	public static void main(String[] args) {
		SpringApplication.run(ItemServiceApplication.class, args);
	}

	@Bean
	@Profile("local")
	public TestDataInit testDataInit(ItemRepository itemRepository) {
		return new TestDataInit(itemRepository);
	}
}

• @Import(MemoryConfig.class) : 앞서 설정한 MemoryConfig 를 설정 파일로 사용한다.
• scanBasePackages = "hello.itemservice.web" : 여기서는 컨트롤러만 컴포넌트 스캔을 사용하고, 나머지는 직접 수동 등록한다. 그래서 컴포넌트 스캔 경로를 hello.itemservice.web 하위로 지정했다.
• @Profile("local") : 특정 프로필의 경우에만 해당 스프링 빈을 등록한다. 여기서는 local 이라는 이름의 프로필이 사용되는 경우에만 testDataInit 이라는 스프링 빈을 등록한다. 이 빈은 앞서 본 것인데, 편의상 초기 데이터를 만들어서 저장하는 빈이다.

프로필이란?
application.properties 에 아래 내용이 있음

spring.profiles.active=local

스프링은 로딩 시점에 application.properties 의 spring.profiles.active 속성을 읽어서 프로필로 사 용한다.
이 프로필은 로컬(나의 PC), 운영 환경, 테스트 실행 등등 다양한 환경에 따라서 다른 설정을 할 때 사용하는 정보이다.
예를 들어서 로컬PC에서는 로컬 PC에 설치된 데이터베이스에 접근해야 하고, 운영 환경에서는 운영 데이터베이스에 접근해야 한다면 서로 설정 정보가 달라야 한다. 심지어 환경에 따라서 다른 스프링 빈을 등록해야 할 수 도 있다. 프로필을 사용하면 이런 문제를 깔끔하게 해결할 수 있다.

위에서 설정한 application.properties 때문에 프로필이 로컬인 부분이 실행 됨.
여기서 local 을 다른 이름으로 변경하면, 테스트 데이터가 들어가지 않음.
지정하지 않으면 default 로 등록됌.

프로젝트엔 test 프로필도 있음.
main 패키지 말고 test 패키지의 application.properties

spring.profiles.active=test

• 이 위치의 application.properties 는 /src/test 하위의 자바 객체를 실행할 때 동작하는 스프링 설정 이다.
• 주로 테스트 케이스를 실행할 때 동작한다.
• spring.profiles.active=test 로 설정하면 스프링은 test 라는 프로필로 동작한다. 이 경우 직전에 설 명한 @Profile("local") 는 프로필 정보가 맞지 않아서 동작하지 않는다. 따라서 testDataInit 이라는 스프링 빈도 등록되지 않고, 초기 데이터도 추가하지 않는다.

initData 를 저장하지 않는 이유 : 이 데이터때문에 테스트가 실패할 수 있기 때문.

프로젝트 구조 설명3 - 테스트

테스트 코드 설명

    @AfterEach
    void afterEach() {
        //MemoryItemRepository 의 경우 제한적으로 사용
        if (itemRepository instanceof MemoryItemRepository) {
            ((MemoryItemRepository) itemRepository).clearStore();
        }
    }

테스트는 서로 영향을 주면 안되기 때문에 각각의 테스트가 끝나면 저장한 데이터를 제거해야함.
메모리 저장소를 완전히 삭제해 다음 테스트에 영향을 주지 않도록 함.
지금 ItemRepository 인터페이스엔 clearStorage 가 없음.
그래서 MemoryItemRepository에 한해서 clearStorage 실행.
다른 데이터베이스는 트랜잭션을 롤백해서 클리어 할 예정이기 때문에 이렇게 했음.

    @Test
    void save() {
        //given
        Item item = new Item("itemA", 10000, 10);

        //when
        Item savedItem = itemRepository.save(item);

        //then
        Item findItem = itemRepository.findById(item.getId()).get();
        assertThat(findItem).isEqualTo(savedItem);
    }

    @Test
    void updateItem() {
        //given
        Item item = new Item("item1", 10000, 10);
        Item savedItem = itemRepository.save(item);
        Long itemId = savedItem.getId();

        //when
        ItemUpdateDto updateParam = new ItemUpdateDto("item2", 20000, 30);
        itemRepository.update(itemId, updateParam);

        //then
        Item findItem = itemRepository.findById(itemId).get();
        assertThat(findItem.getItemName()).isEqualTo(updateParam.getItemName());
        assertThat(findItem.getPrice()).isEqualTo(updateParam.getPrice());
        assertThat(findItem.getQuantity()).isEqualTo(updateParam.getQuantity());
    }

    @Test
    void findItems() {
        //given
        Item item1 = new Item("itemA-1", 10000, 10);
        Item item2 = new Item("itemA-2", 20000, 20);
        Item item3 = new Item("itemB-1", 30000, 30);

        itemRepository.save(item1);
        itemRepository.save(item2);
        itemRepository.save(item3);

        //둘 다 없음 검증
        test(null, null, item1, item2, item3);
        test("", null, item1, item2, item3); // 문자는 길이가 0 이어도 null 로 인지

        //itemName 검증
        test("itemA", null, item1, item2);
        test("temA", null, item1, item2);
        test("itemB", null, item3);

        //maxPrice 검증
        test(null, 10000, item1);

        //둘 다 있음 검증
        test("itemA", 10000, item1);
    }

    void test(String itemName, Integer maxPrice, Item... items) {
        List<Item> result = itemRepository.findAll(new ItemSearchCond(itemName, maxPrice));
        assertThat(result).containsExactly(items);
    }

• save() : 잘 저장됬는지 확인.
• updateItem() : 하나 업데이트 해보고 수정 잘 되는지 확인
• findItems() : 3개 저장하고, 저장 조건에 따라 잘 조회 되는지 확인
  • containsExactly : 순서까지 일치해야 검증 성공

인터페이스를 테스트하자
여기서는 MemoryItemRepository 구현체를 테스트 하는 것이 아니라 ItemRepository 인터페이스를 테스트하는 것을 확인할 수 있다. 인터페이스를 대상으로 테스트하면 향후 다른 구현체로 변경되었을 때 해당 구 현체가 잘 동작하는지 같은 테스트로 편리하게 검증할 수 있다.

데이터베이스 테이블 생성

h2 데이터베이스에 아래 명령어로 테이블 생성

 drop table if exists item CASCADE;
 create table item
 (
     id        bigint generated by default as identity,
     item_name varchar(10),
     price     integer,
     quantity  integer,
     primary key (id)
 );

• generated by default as identity
  • identity 전략이라고 하는데, 기본 키 생성을 데이터베이스에 위임하는 방법이다. MySQL의 Auto Increment와 같은 방법이다.
  • 여기서 PK로 사용되는 id 는 개발자가 직접 지정하는 것이 아니라 비워두고 저장하면 된다. 그러면 데이터 베이스가 순서대로 증가하는 값을 사용해서 넣어준다.

insert into item(item_name, price, quantity) values ('ItemTest', 10000, 10)
로 넣어주면 아이템이 잘 저장됨
아이디가 자동 증가하네? 다른 유니크한 값으로 하면 안되나?

참고 - 권장하는 식별자 선택 전략

데이터베이스 기본 키는 다음 3가지 조건을 모두 만족해야 한다.

1. null 값은 허용하지 않는다.
2. 유일해야 한다.
3. 변해선 안 된다.

테이블의 기본 키를 선택하는 전략은 크게 2가지가 있다.

• 자연 키(natural key)
  • 비즈니스에 의미가 있는 키
  • 예: 주민등록번호, 이메일, 전화번호
• 대리 키(surrogate key)
  • 비즈니스와 관련 없는 임의로 만들어진 키, 대체 키로도 불린다.
  • 예: 오라클 시퀀스, auto_increment, identity, 키생성 테이블 사용

자연 키보다는 대리 키를 권장한다
현재가 아니라 미래도 변하면 안되기 때문에 자연 키보단 대리 키를 권장

비즈니스 환경은 언젠가 변한다
과거에 주민등록번호를 기본 키로 잡았는데 주민등록번호를 저장하지 않는거로 법이 바뀌어서 코드 대량 수정이 발생했음.
대리 키는 비즈니스와 무관한 임의 의 값이므로 요구사항이 변경되어도 기본 키가 변경되는 일은 드물다. 대리 키를 기본 키로 사용하되 주민등록번호나 이 메일처럼 자연 키의 후보가 되는 컬럼들은 필요에 따라 유니크 인덱스를 설정해서 사용하는 것을 권장한다.
비즈니스 요구사항은 계속해서 변하는데 테이블은 한 번 정의하면 변경하기 어렵다. 그런면에서 외부 풍파에 쉽게 흔들 리지 않는 대리 키가 일반적으로 좋은 선택이라 생각한다.

[6om1n]

열심히 하시고 계시는군여 !!!!!
DB2편도 파이팅입니다 ~~~~

[YuDeokRin]

고생하셨습니다! DB도 팟팅