이번시간에는 H2 데이터 베이스를 사용하여 DB를 연동하고 4가지 스프링 DB 접근 기술을 적용해보며 장단점을 비교해보겠습니다.
이전에 스프링 설정으로 맴버 서비스와 리포지토리를 컨테이너에 등록하여 DI를 변경하기 쉽도록 구현해 놓았습니다. 따라서, 기술들을 차례대로 구현하면서 설정을 변경하여 DI해주고 테스트도 진행해 보겠습니다.
H2 데이터베이스 설치
DB 연동을 위해 데이터베이스를 준비하겠습니다.
MySQL 계열의 H2 데이터 베이스를 셋팅합니다. 개발이나 테스트 용도로 가볍고 편리한 DB이며, 웹 화면도 제공합니다.
다운로드 및 설치
정상적인 동작을 위해 스프링 부트 버전에 맞추어 1.4.200 버전을 다운받고 설치합니다.
실행 (윈도우 기준)
커멘드 창을 열고 H2/bin 경로에서 h2.bat 으로 실행
데이터베이스 파일 생성 후 접속
jdbc:h2:~/test (최초 한번)
~/test.mv.db 파일 생성 확인
이후부터는 jdbc:h2:tcp://localhost/~/test 이렇게 접속
테이블 생성
H2 데이터베이스에 접근하여 member 테이블 생성
테이블 관리를 위해 프로젝트 루트에 sql/ddl.sql 파일을 생성하여 쿼리 저장
순수 Jdbc 리포지토리 구현
환경 설정
build.gradle 파일에 jdbc, h2 데이터베이스 관련 라이브러리 추가
스프링 부트 데이터베이스 연결 설정 추가
Jdbc 리포지토리 구현 JDBC API로 직접 코딩하는 것은 20년 전에 사용하던 방식입니다. 따라서, 참고만 하고 넘어갑니다. 코드는 생략하겠습니다.
Spring을 통해 데이터소스를 주입받는다.
데이터소스에서 커낵션을해서 sql을 작성하고 excute해서 쿼리를 날린다.
DataSource는 데이터베이스 커넥션을 획득할 때 사용하는 객체입니다. 스프링 부트는 데이터베이스 커넥션 정보를 바탕으로 DataSource를 생성하고 스프링 빈으로 만들어둡니다.따라서 DI를 받을 수 있습니다.
구현 클래스를 추가한 구조는 다음과 같습니다.
스프링 설정을 통해 구현 클래스 DI를 변경합니다.
개방-폐쇄 원칙(OCP, Open-Closed Priciple)을 지키면서 손쉽게 구현 클래스를 변경하였습니다.
확장에는 열려있고, 수정(변경)에는 닫혀있다.
객체지향의 다형성의 개념을 활용하면 이렇게 기능을 완전히 변경해도 애플리케이션 전체를 수정할 필요가 없습니다. 조립하는 코드만 수정하면 기능을 완전히 변경할 수 있습니다.
스프링의 DI(Dependencies Injection)을 사용하면 "기존 코드를 전혀 손대지 않고, 설정만으로 구현 클래스를 변경"할 수 있습니다.
스프링 통합 테스트
스프링 컨테이너와 DB까지 연결한 통합 테스트를 진행해보겠습니다. 이전의 테스트 코드는 순수 자바 테스트 코드입니다. 지금은 DB 접근 정보(DataSource)를 스프링 부트에서 관리하고 있기 때문에 테스트를 스프링과 연동하여 진행해야 합니다.
@SpringBootTest: 스프링 컨테이너와 테스트를 함께 실행합니다.
@Transactional: 테스트 케이스에 이 어노테이션이 있으면, 테스트 시작 전에 트랙잭션을 시작하고, 테스트 완료 후에 항상 롤백한다. 이렇게 하면 DB에 데이터가 남지 않으므로 다음 테스트에 영향을 주지 않습니다.
스프링 JdbcTemplate
순수 Jdbc와 환경설정이 동일합니다.
스프링 JdbcTemplate과 Mybatis 같은 라이브러리는 JDBC API에서 본 반복 코드를 대부분 제거해줍니다. 하지만 SQL은 직접 작성해야 합니다.
왜 템플릿인가?
디자인 패턴 중 템플릿 메서드 패턴을 많이 활용하여 코드를 줄였기 때문 등등...
스프링 JdbcTemplate 회원 리포지토리를 생성하고,JdbcTemplate을 사용하도록 스프링 설정 변경합니다.
JPA
JPA는 기존의 반복 코드는 물론이고, 기본적인 SQL도 JPA가 직접 만들어서 실행해줍니다.
JPA를 사용하면, SQL과 데이터 중심의 설계에서 객체 중심의 설계로 패러다임을 전환할 수 있습니다.
JPA를 사용하면 개발 생산성을 크게 높일 수 있습니다.
build.gradle 파일에 JPA, h2 관련 라이브러리 추가
spring-boot-starter-data-jpa는 내부에 jdbc 관련 라이브러리를 포함하기 때문에 jdbc는 제거합니다.
스프링 부트에 JPA설정 추가
show-sql:JPA가 생성하는 SQL출력, ddl-auto: 테이블 자동생성 기능 (none: 끄기, create: 엔티티 정보로 테이블 직접 생성)
JPA 엔티티 매핑
@Entitiy 사용
@Id 지정
@GeneratedValue(startedy = GenerationType.IDENTITY) 설정
JPA 회원 리포지토리 구현
서비스 계층에 트랜잭션 추가
org.springframework.transaction.annotation.Transactional 사용
스프링은 해당 클래스의 메서드를 실행할 때 트랙잭션을 시작하고, 메서드가 정상 종료되면 트랜잭션을 커밋합니다. 만약 런타임 예외가 발생하면 롤백합니다.
JPA를 통한 모든 데이터 변경은 트랜잭션 안에서 실행해야 합니다.
JPA를 사용하도록 스프링 설정 변경
스프링 데이터 JPA
JPA도 좋은데... 스프링 데이터 JPA는 더?
스프링 부트와 JPA만 사용해도 개발 생산성이 정말 많이 증가하고, 개발해야할 코드도 확연히 줄어듭니다.
여기에 스프링 데이터 JPA를 사용하면, 기존의 한계를 넘어 마치 마법처럼, 리포지토리에 구현 클래스 없이 인터페이스 만으로 개발을 완료할 수 있습니다.
그리고 반복 개발해온 기본 CRUD 기능도 스프링 데이터 JPA가 모두 제공합니다.
Spring Data JPA는 왜 써야 하는가?
스프링 부트와 JPA라는 기반 위에, 스프링 데이터 JPA라는 환상적인 프레임워크를 더하면 개발이 정말 즐거워집니다.
지금까지 조금이라도 단순하고 반복이라 생각했던 개발 코드들이 확연하게 줄어듭니다.
따라서 개발자는 핵심 비즈니스 로직을 개발하는데, 집중할 수 있습니다.
실무에서 관계형 데이터베이스를 사용한다면 스프링 데이터 JPA는 이제 선택이 아니라 필수 입니다.
앞의 JPA 설정을 그대로 사용합니다.
스프링 데이터 JPA 회원 리포지토리를 구현하고, 스프링 데이터 JPA 회원 리포지토리를 사용하도록 스프링 설정을 변경합니다.
스프링 데이터 JPA가 SpringDataJpaMemberRepository를 스프링 빈으로 자동 등록해줍니다.
스프링 데이터 JPA는 다음과 같이 클래스를 제공하며 기능들이 구현되어있습니다.
인터페이스를 통한 기본적인 CRUD 기능
findByName(), findByEmail() 처럼 메서드 이름 만으로 조회 기능 제공
페이징 기능 자동 제공
참고
실무에서는 JPA와 스프링 데이터 JPA를 기본으로 사용하고, 복잡한 동적 쿼리는 Querydsl이라는 라이브러리를 사용하면됩니다. Querydsl을 사용하면 쿼리도 자바 코드로 안전하게 작성할 수 있고, 동적 쿼리를 편리하게 작성할 수 있습니다. 이 조합으로 해결하기 어려운 쿼리는 JPA가 제공하는 네이티브 쿼리를 사용하거나, 앞서 학습한 스프링 JdbcTemplate를 사용하면 됩니다.
지금까지 멤버의 객체, 서비스, 리포지토리를 만들었습니다.앞으로 회원 가입을 하고 회원 목록을 보여주는 컨트롤러를 작업할 것입니다. 컨트롤러에서 맴버 서비스와 리포지토리를 통해서 회원가입을하고 데이터를 조회할 수 있어야합니다. 이러한 관계를 컨트롤러가 서비스를 의존한다고 하며, 스프링의 방식으로 의존관계를 설정해보겠습니다.
컴포넌트 스캔과 자동 의존관계 설정
우선 멤버 컨트롤러를 만들어줍니다. 이때, @Controller라는 어노테이션이 있으면 스프링이 뜰 때 객체를 생성해서 스프링 컨테이너에서 관리를 합니다. 그렇기 때문에 스프링과 관련된 기능들이 동작할 수 있게 됩니다. @Autowired 어노테이션으로 Spring 컨테이너에서 Member 서비스를 가져옵니다.
기존에 작성된 맴버 서비스는 순수 자바 클래스 입니다. 따라서, 스프링에서 알 수 있도록 @Service를 붙여줍니다. 그리고, 맴버 리포지토리를 사용할 수 있도록 @Autowired로 리포지토리를 연결합니다.
리포지토리도 마찬가지로 구현체에 @Repository 를 붙여 스프링에서 알 수 있도록 해줍니다.
멤버 컨트롤러에서 사용할 수 있도록 서비스를 @Autowired 해주는 것, 서비스에서 리포지토리를 사용할 수 있도록 @Autorwired 해주는 것을 의존성을 주입한다고 합니다. 참고로, 생성자가 1개만 있으면 @Autowired는 생략가능합니다.
스프링 빈 등록 이미지
등록된 스프링 빈 의존관계를 표현하면 다음과 같습니다.
스프링 빈을 등록하는 방법은 2가지가 있습니다. 2가지 방법을 모두 알아야합니다.
우선 앞서 등록한 방식을 컴포넌트 스캔 방식이라고 하며 원리는 다음과 같습니다.
컴포넌트 스캔 원리
@Conponent 어노테이션이 있으면 스프링 빈으로 자동 등록된다.
@Component 를 포함하는 다음 어노테이션들은 컴포넌트 스캔으로 스프링 빈으로 자동 등록됩니다.
@Controller
@Service
@Repository
스프링은 컨테이너에 스프링 빈을 등록할 때, 기본으로 싱글톤으로 등록합니다.(유일하게 하나만 등록해서 공유한다.) 따라서 같은 스프링 빈이면 모두 같은 인스턴스입니다.
자바 코드로 직접 스프링 빈 등록하기
향후 메모리 리포지토리를 다른 리포지토리로 변경할 예정이므로, 회원 서비스와 리포지토리의 @Service, @Repository, @Aurowired 어노테이션을 제거하고 자바 코드로 직접 스프링 빈을 등록해보겠습니다.
SpringConfig를 직접 작성합니다.
@Configuration 을 등록하고, @Bean으로 작성합니다.
Controller는 스프링이 관리하는 것이기 때문에 어쩔 수 없음, 컴포넌트 스캔방식으로 하면 됩니다.
참고사항
DI에는 필드 주입, setter 주입, 생성자 주입 3가지 방식이 있습니다. 의존관계가 실행중에 동적으로 변경하는 경우가 거의 없으므로 (실무에서는 거의 0) 생성자 주입을 주로 사용하며 권장합니다.
필드 주입은 DI를 사용하여 객체를 바꿀 수 있는 방법이 없어 권장하지 않습니다.
Setter 방식은 public으로 열려있어 set으로 다른 곳에서도 조작 가능합니다. 실행되는 어플리케이션은 변경되면 곤란합니다.
당연한 이야기이지만 @Autowired를 통한 DI는 스프링이 관리하는 객체 (스프링 컨테이너에 등록된 스프링 빈) 에서만 동작합니다. 스프링 빈으로 등록하지 않고 직접 생성한 객체에서는 동작하지 않습니다.
정형화된 컨트롤러, 서비스, 리포지토리는 컴포넌트 스캔을 사용합니다. 정형화 되지 않거나, 상황에 따라 구현 클래스를 변경해야 하면 설정을 통해 스프링 빈으로 등록합니다.
앞서 웹 개발 방법을 비교 학습해보았습니다. 이번에는 아주 간단한 회원 관리 예제를 통해 실습을 해보겠습니다. 개발 순서은 다음과 같이 진행하겠습니다.
비지니스 요구사항 정리
회원 도메인과 리포지토리 만들기
회원 리포지토리 메모리 구현체 테스트
회원 서비스 개발
회원 서비스 테스트
비지니스 요구사항 정리
데이터: 회원ID, 이름
기능: 회원 등록, 조회
데이터 저장소는 미정인 시나리오를 가정하고 개발 시작
일반적인 웹 어플리케이션 계층 구조
컨트롤러: 웹 MVC의 컨트롤러 역할
서비스: 핵심 비지니스 로직 구현
리포지토리: 데이터베이스에 접근, 도메인 객체를 DB에 저장하고 관리
도메인: 비지니스 도메인 객체. 예) 회원, 주문, 쿠폰 등을 주로 데이터베이스에 저장하고 관리됨
클래스 의존관계
데이터 저장소가 미정인 상황임으로, 우선 인터페이스로 구현 클래스를 변경할 수 있도록 설계
데이터 저장소는 RDB, NoSQL등 다양한 저장소를 고민중인 상황으로 가정
개발을 진행하기 위해서 초기 개발 단계에서는 구현체로 가벼운 메모리 기반의 데이터 저장소 사용
회원 도메인과 리포지토리 만들기
객체, 리포지토리 인터페이스, 리포지토리 구현체를 만들어줍니다.
Optional: Java 8 의 기능, null 처리 방법, Null이 될 가능성이 있을경우 Optional.ofNullable 을 감싼다
MemoryMemberRepository 에서 저장하기 위한 변수 생성
공유되는 변수일 때에는 동시성 문제가 있을 수 있기 때문에 실무에서는 concurrent 해시를 사용해야지만, 예제임으로 HashMap으로 진행
마찬가지로 sequence도 Long이 아니라, Atomic Long을 사용해야하지만 예제임으로 그냥 Long 사용
findByName
Java 8의 Lambda 사용
회원 리포지토리 메모리 구현체 테스트
개발한 기능을 실행해서 테스트할 때 자바의 main 메소드를 통해서 실행하거나 웹 어플리케이션의 컨트롤러를 통해서 해당 기능을 실행한다. 이러한 방법은 준비하고 실행하는데 오래 걸리고, 반복 실행하기 어렵고 여러 테스트를 한번에 실행하기 어렵다는 단점이 있다. 자바는 JUnit이라는 프레임워크로 테스트를 실행해서 이런한 문제를 해결한다.
Assertions
org.assertj.core.api.Assertions.*;가 사용이 편리하여 잘 이용되며, static으로 import하여 쓰면 assertThat과 같은 기능을 바로 사용하기 편리하다.
테스트는 순서와 상관없이 서로 의존 관계없이 설계되어야 한다. 따라서, 하나의 테스트가 끝나면 저장소와 같은 공유되는 것을 초기화 해주어야한다. 그러므로 @AfterEach를 사용해 repository를 지우도록 한다.
테스트 케이스를 먼저 작성하고 클래스를 만들어 동작을 확인 하는 방식을 TDD라고 한다.
회원 서비스 개발
비지니스 로직을 작성한다.
회원 이름 중복 검증로직을 작성하는데, 이를 함수화하면 재사용성을 높일 수 있다.
회원 서비스 테스트
서비스에서 테스트 만들기를 통해 쉽게 만들 수 있다.
서비스 테스트 리포지토리가 서로 다른 객체인 것을, 서비스에서 MemberRepository를 직접 생성하는 것이 아니라 외부에서 넣어주도록 변경
