2021-03-25(Thu)

항목	내용
학습 날짜	2021-03-25(목)
학습 시간	11:00~23:00
학습 범위 및 주제	스프링부트
학습 목표	스프링부트 기본 개념을 학습한다.
동료 학습 방법	-

상세 학습 내용

JPA?

현대의 웹 애플리케이션에서 관계형 데이터베이스(RDB, Relational Database)는 빠질 수 없는 요소이다. 그러다보니 객체를 관계형 데이터베이스에서 관리하는 것이 무엇보다 중요하다.

관계형 데이터베이스가 계쏙해서 웹 서비스의 중심이 되면서 모든 코드는 SQL 중심이 되어가며, 현업 프로젝트 대부분이 애플리케이션 코드보다 SQL로 가득하게 되었다.

이는 관계형 데이터베이스가 SQL만 인식할 수 있기 때문인데, 그래서 각 테이블마다 기본적인 CRUD SQL을 매번 생성해야 했다. 아무리 자바 클래스를 아름답게 설계를 해도 SQL을 피할 수 없다.

이런 상황에서 다음 두 문제가 발생한다.

1. 반복 작업

   수백 개의 테이블이 있는데 이 테이블의 몇 배의 SQL을 만들고 유지보수 해야하만 한다.

2. 패러다임 불일치

   데이터베이스는 어떻게 데이터를 저장할지에 초점이 맞춰진 기술이다. 객체지향 프로그래밍 언어는 메시지를 기반으로 기능과 속성을 한 곳에서 관리하는 기술이다. 그런데 상속, 1:N 등 다양한 객체 모델링을 데이터베이스로는 구현할 수 없다. 그러다보니 웹 애플리케이션 개발은 점점 데이터베이스 모델링에만 집중하게 된다. 그리고 SQL에 종속적인 개발을 하게 된다.

JPA는 위 두 문제를 해결하기 위해 등장했다. 1) 반복을 줄이고 2) 중간에서 패러다임 일치를 시켜준다.

Spring Data JPA

JPA는 인터페이스로서 자바 표준명세서이다. 인터페이스인 JPA를 사용하기 위해서는 구현체가 필요하다. 대표적으로 Hibernate, Eclipse Link 등이 있지만, Spring에서 JPA를 사용할 때는 이 구현체들을 직접 다루진 않는다. 구현체들을 한번 더 추상화시킨 Spring Data JPA라는 모듈을 이용해서 JPA 기술을 다룬다.

이를 통해 아래 두 이점을 가진다.

• 구현체 교체의 용이성 ex) Redis 클라이언트를 Jedis에서 Lettuce로 변경할 때

• 저장소 교체의 용이성(관계형 데이터베이스 외에 다른 저장소로 쉽게 교체) ex) 트래픽이 많아져서 관계형 데이터베이스로는 감당이 되지 않을 때 MongoDB로 교체가 필요하다면 Spring Data JPA에서 Spring Data MongoDB로 의존성만 교체하면 됨.

실무에서의 JPA

실무에서는 높은 러닝 커브 때문에 JPA를 잘 사용하지 못하곤 한다. 객체지향 프로그래밍과 관계형 데이터베이스를 둘 다 이해해야하기 때문이다. 속도 이슈는 해결책이 많아서 잘 쓰면 충분히 네이티브 쿼리만큼의 퍼포먼스를 낼 수 있다.

Repository

Respository는 ibatis나 MyBatis 등에서는 Dao라고 불리는 DB Layer 접근자이다. JPA에선 Repository라고 부르며 인터페이스로 생성하는 것이다. 단순히 인터페이스를 생성 후, JpaRepository<Entity 클래스, PK 타입>을 상속하면 기본적인 CRUD 메소드가 자동으로 생성된다.

주의 할점

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

• Entity 클래스와 기본 Entity Repository는 함께 위치해야 한다. Entity 클래스는 기본 Repository 없이는 제대로 역할을 할 수가 없다.

생성자 vs 빌더 클래스

빌더 클래스는 @Builder를 통해 제공할 수 있다. 생성자나 빌더나 생성 시점에 값을 채워주는 역할은 똑같다. 다만, 생서자는 지금 채워야 할 필드가 무엇인지 명확히 지정할 수가 없다. 반면 빌더는 어느 필드에 어떤 값을 채워야할지 명확하게 인지할 수 있다.

JPA의 영속성 컨텍스트과 더티 체킹

영속성 컨텍스트란 엔티티를 영구 저장하는 환경이다. 일종의 논리적 개념이며, JPA의 핵심 내용은 엔티티가 영속성 컨텍스트에 포함되어 있냐 아니냐로 갈린다. JPA의 엔티티 매니저가 활성화된 상태로(Spring Data JPA를 쓴다면 기본 옵션임) 트랜잭션 안에서 데이터베이스로부터 데이터를 가져오면 이 데이터는 영속성 컨텍스트가 유지된 상태이다.

이 상태에서 해당 데이터의 값을 변경하면 트랜잭션이 끝나는 시점에 해당 테이블에 변경분을 반영한다. 즉, Entity 객체의 값만 변경하면 별도로 Update 쿼리를 날릴 필요가 업다는 것이다. 이 개념을 더티 체킹(Dirty Checking)이라고 한다.

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

보통 엔티티에는 해당 데이터의 생성시간과 수정시간을 포함한다. 유지보수에 유용한 정보이기 때문이다. 문제는 매번 DB에 삽입하기 전, 갱신하기 전에 날짜 데이터를 등록/수정하는 코드가 여기저기 들어가게 된다.

public void savePosts() {
  ...
  posts.setCreateDate(new LocalDate());
  postsRepository.save(posts);
  ...
}

이런 중복은 JPA Auditing으로 해결할 수 있다.

LocalDate 사용

Java8부터 LocalDate와 LocalDateTime이 등장했다. 기존 Date 타입의 문제점을 고친 타입이라 Java8이면 무조건 써야한다고 생각하면 된다.

참고로 기존 Date 타입의 문제점은 아래와 같다.

1. 불변(변경이 불가능한) 객체가 아니다.

   멀티스레드 환경에서 언제든 문제가 발생할 수 있다.

2. Calendar는 월(Month) 값 설계가 잘못되었다.

   10월을 나타내는 Calendar.OCTOBER의 숫자 값은 '9'이다.

Spring 웹 계층에 대해

Spring은 아래 5가지 계층으로 이루어져 있다.

• Web Layer

  • 흔히 사용하는 컨트롤러와 JSP/Freemarker 등의 뷰 템플릿 영역이다.

  • 이외에도 필터, 인터셉터, 컨트롤러 어드바이스 등 외부 요청과 응답에 대한 전반적인 영역을 다룬다.

• Service Layer

  • @Service에 사용되는 서비스 영역이다.

  • 일반적으로 Controller와 Dao의 중간 영역에서 사용된다.

  • @Transactional이 사용되어야 하는 영역이기도 한다.

• Repository Layer

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

• Dtos

  • Dto(Data Transfer Object) 계층 간에 데이터 교환을 위한 객체를 이야기한다.

  • 예를 들어 뷰 템플릿 엔진에서 사용될 객체나 Repository Layer에서 결과로 넘겨준 객체 등이 이들을 이야기한다.

• Domain model Layer

  • 도메인이라 불리는 개발 대상을 모든 사람이 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화시킨 것을 도메인 모델이라고 한다. 비즈니스 처리를 담당해야할 곳이다.

참고

Entity 클래스를 Request/Response 클래스로 사용해서는 안 된다. 왤까? Entity 클래스는 데이터베이스와 맞닿은 핵심 클래스이기 때문이다. Entity 클래스를 기준으로 테이블이 생성되고, 스키마가 변경된다. 화면 변경은 아주 사소한 기능 변경인데, 이를 위해 테이블과 연결된 Entity 클래스를 변경하는 것은 너무 큰 변경이다. 반면 Request와 Response용 Dto는 View를 위한 클래스라 정말 자주 변경이 필요하다.

서버 템플릿 엔진과 머스테치(Mustache)

웹 개발에서 템플릿 엔진이란, 지정된 템플릿 양식과 데이터가 합쳐져 HTML 문서를 출력하는 소프트웨어를 이야기한다. JSP, Freemarker 등의 서버 템플릿 엔진이나 리액트, 뷰의 View 파일 같은 클라이언트 템플릿 엔진들이 여기에 속한다.

둘 모두 결과적으로 지정된 템플릿과 데이터를 이용하여 HTML을 생성하는 템플릿 엔진이다.

서버 템플릿 엔진을 이용해서 화면을 생성한다면, 서버에서 Java 코드로 문자열을 만든 뒤 이 문자열을 HTML로 변환하여 브라우저로 전달한다.

아래처럼 코드를 작성하면 HTML을 만드는 과정에서 System.out.println("test"); 를 실행할 뿐이다. 이 때의 자바스크립트 코드는 단순한 문자열일 뿐이다.

<script type="text/javascript">
​
$(document).ready(function() {
  if(a=="1") {
    <%
      System.out.println("test");
    %>
  }
}

반면에 자바스크립트는 브라우저 위에서 작동한다. 앞에서 작성된 자바스크립트 코드가 실행되는 장소는 서버가 아닌 브라우저이다. 즉, 브라우저에서 작동될 때는 서버 템플릿 엔진의 손을 벗어나 제어할 수 없다.

머스테치는 수많은 언어를 지원하는 가장 심플한 템플릿 엔진이다.

• JSP, Velocity: 스프링 부트에서는 권장하지 않는 템플릿 엔진이다.

• Freemarker: 템플릿 엔진으로는 너무 과하게 많은 기능을 지원한다. 때문에 숙련도가 낮으면 Freemarker 안에 비즈니스 로직이 추가될 확률이 높다.

• Thymeleaf: 스프링 진영에서 적극적으로 밀고 있지만 문법이 어렵다.

• 머스테치: 문법이 다른 템플릿 엔빈보다 심플하고, 로직코드를 사용할 수 없어서 View의 역할과 서버의 역할이 명확하게 분리된다.

참고

규모가 있는 프로젝트에서의 데이터 조회는 FK의 조인, 복잡한 조건 등으로 인해 이런 Entity 클래스만으로 처리하기 어려워 조회용 프레임워크를 추가로 사용한다. 대표적으로 querydsl, jooq, MyBatis 등이 있따. 조회는 이 3가지 프레임워크 중 하나를 통해 조회하고, 등록/수정/삭제 등은 SpringDataJpa를 통해 진행한다.

이 중 아래 이유에서 Querydsl을 추천한다.

1. 타입 안정성이 보장된다.

   단순한 문자열로 쿼리를 생성하는 것이 아니라, 메소드를 기반으로 쿼리를 생성하기 때문에 오타나 존재하지 않는 컬럼명을 명시할 경우 IDE에서 자동으로 검출된다. 이 장점은 Jooq에서도 지원하지만, MyBatis에서는 지원하지 않는다.

2. 국내 많은 회사에서 사용 중이다.

   쿠팡, 배민 등 JPA를 적극적으로 사용하는 회사에서는 Querydsl을 적극적으로 사용 중이다.

3. 레퍼런스가 많다.

   2번 장점과 이어지는 것.

학습 내용에 대한 개인적인 총평

스프링 부트를 학습하지 않고, 자바를 학습하지 않고 책을 따라치는데도 생각보다 잘 이해가 된다. 그간 학습한 것 덕분에 속도가 빨라지긴 했나보다.

더불어서 스프링을 쓰는 곳에는 당장 취업할 수는 없겠다는 예감이 강하게 들었다. 일단 로그를 읽는 것도 어렵구만, 레일즈가 얼마나 친절한 프레임워크였는지 다시금 느낀다.

다음 학습 계획

• 스프링부트 학습