Week04

객체 지향 언어와 관계형 데이터 베이스

차이점

• 스프링의 자바는 객체 지향 언어
• 데이터를 관리하기 위해 사용하는 것은 관계형 데이터베이스
• 자바의 목표 → 캡슐화/상속/다형성을 활용하는 것
• 관계형 DB의 목표 → 데이터를 정교하게 구성하는 것
• 즉, 스프링 부트를 활용하기 위해 CRUD 쿼리를 다 짜고, 자바 코드를 SQL로 바꾸고 SQL쿼리를 자바로 바꾸는 번거로운 과정이 필요하다
• DB에서 조회한 테이블 형식의 데이터들을 자바 객체로 변환하는 과정이 필요하고 변경된 객체의 상태를 다시 SQL로 변환하여 관계형 DB에 반영해야 한다

JPA

• 자바 진영에서 ORM(객체 관계형 매핑) 기술의 표준으로 사용되는 인터페이스의 모음
• ORM : 애플리케이션 클래스와 관계형 DB의 테이블을 매핑(연결)하는 기술
• 즉, JPA를 사용함으로서 반복적인 CRUD SQL 쿼리문을 직접 짤 필요가 없이 자동으로 매핑하여 날려준다
• 인터페이스의 모음인 마늠 실제로 구현되는 것이 아니라, 개발자가 구현한 클래스와 매핑을 해주기 위해 사용되는 프레임워크이다

스프링 프로젝트 및 설계 구조

프로젝트 구조

대표적으로 많이 사용하는 프로젝트 구조는 아래와 같다

• 파사드 패턴 구조
• 도메인형 구조
• 계층형 구조
• 헥사고날 구조

각 구조에는 모두 각자의 장단점이 존재한다. 그 중 도메인형 구조는 ERD를 기준으로 도메인을 만들기 쉽고, 협업 시 도메인별로 역할을 분담하기도 쉽다

도메인형 구조

• 만들어진 DRD의 도메인을 살펴보면 크게 4가지로 나뉘게 된다. 사용자, 미션, 리뷰, 가게이다
• 이걸 기준으로 생성된 프로젝트 구조는 아래와 같다

 project root
 ├── domain
 │   ├── member
 │   ├── mission
 │   ├── review
 │   └── store
 │     ├── controller
 │     ├── converter : DTO → Entity 간의 변환을 담당 (서비스 레이어가 비즈니스 로직에만 집중할 수 있도록 함)
 │     ├── dto
 │     ├── entity
 │     ├── repository
 │     └── service
 └── global : 전역으로 사용되는 객체(설정, 예외 처리 등)를 담는 디렉토리

엔티티 매핑

사용되는 어노테이션은 아래와 같다

• @Entity : 해당 클래스가 JPA의 엔티티임을 의미
• @Table : DB의 테이블을 정의. (name="member") 등으로 테이블의 이름을 명시하는 등의 옵션을 사용할 수 있음
• @Id : 해당 어트리뷰트가 해당 엔티티의 PK라는 것을 의미
• @GeneratedValue : 주로 id 필드와 함께 사용. 값을 넣어주지 않더라도 자동으로 번호가 생성됨
• @Column : 해당 어트리뷰트가 해당 엔티티의 칼럼이라는 것을 의미. (name="gender") 등으로 칼럼명을 명시하는 등의 옵션을 사용할 수 있음
• @Enumerated : Enum을 사용할 때, 데이터의 형태를 명시화
• @NoArgsConstructor : 기본 생성자를 자동으로 생성합니다. JPA 엔티티는 내부적으로 기본 생성자를 필요로 하므로 기본 생성자를 반드시 작성해야 한다. 다만 개발자는 기본 생성자로 객체를 만들 일이 거의 없으므로 (access = AccessLevel.PROTECTED) 옵션을 이용해 기본 생성자를 protected로 처리한다

DBMS 내부에서 예약어, 키워드로 예약된 단어(ex. User)를 내 프로젝트의 클래스명이나 칼럼명으로 쓰지 않도록 주의해야 한다!

세부 설정

// 이름 칼럼은 3글자로 제한되며 null값을 넣을 수 없다
@Column(length = 3, nullabel = false)
private String name;

초기값 지정

// 이름 칼럼은 문자열 Enum 클래스의 값을 갖는다
// null값을 넣을 수 없으며 값을 넣지 않을 경우 NONE으로 초기화된다
@Column(nullabel = false)
@Enumerated(EnumType.STRING)
@Builder.Default        // lombok 라이브러리에서 지원
private Gender gender = Gender.NONE;

이때 @Buileder.Default를 사용하기 위해서는 상단 클래스에 @Builder 어노테이션을 명시해야 한다

생성/수정 일자 자동 기입

// 생성 일자
@CreatedDate
@Column(nullabel = false)
private LocalDateTime createAt;

// 수정 일자
@LastModifiedDate
@Column(nullabel = false)
private LocalDateTime updateAt;

이때 @CreatedDate와 @LastModifiedDate를 사용하기 위해서는 상단 클래스에 @EnableJpaAuditing와 @EntityListeners(AuditingEntityListener.class) 어노테이션을 명시해야 한다

BaseEntity 설정

• 만약 CreatedAt, UpdatedAt처럼 모든 엔티티에서 공통으로 사용되는 어트리뷰트가 사용된다면 BaseEntity 설정을 사용할 수 있다
• BaseEntity 클래스를 만들어 공통된 속성을 정의하고 원하는 클래스에서 extends BaseEntity 처리를 해주면 된다
• 일반적인 칼럼은 조인 시 충돌을 피하기 위해 이름을 다르게 매핑하는 것(user_name, shop_name 등)이 일반적이지만 BaseEntity의 공통 컬럼은 모든 엔티티에서 동일한 의미를 가지므로 일관성을 위해 같은 이름을 사용해도 문제가 없다
• 또한 created_at이나 updated_at 같은 Auditing 컬럼은 데이터를 조회하거나 디버깅할 때 유용한 메타 데이터이기 때문에, 두 테이블을 연결하는 조인 조건으로 사용될 일이 없다

연관 관계 지정

• N:M 연관관계의 경우 중간 테이블을 생성하고 그곳에서 연관 관계를 지정한다
• @OneToOne : 1:1 연관관계 설정
• @ManyToOne : 1:N 관계에서 이 엔티티가 N임을 정의한다
• @JoinColumn : 해당 어노테이션을 가진 클래스(테이블)이 이 연관 관계의 주인임을(FK의 주인임을) 설정한다
• 이때 ~ToOne의 경우 @JoinColumn에서 (fatch = FetchType.LAZY)를 명시해 지연 로딩을 설정하는 것이 권장된다
• 매핑 당하는 쪽의 경우 @OneToOne 등의 어노테이션에서 (mappedBy = “reply")를 명시하면 된다

N+1 문제

FetchType.EAGER의 작동 방식 및 문제점

• FetchType.EAGER을 설정하면, 해당 엔티티를 로딩할 때 연관된(FK로 묶인) 다른 테이블의 내용까지 즉시 한 번에 같이 로딩된다
• 이는 개발자가 원하지 않는 데이터까지 미리 가져오게 만들어 어플리케이션의 성능을 저하한다
• 또한 ORM(Object-Relational Mapping)의 설계 원칙 중 하나인 필요할 때 필요한 정보만 가져온다는 원칙을 위배한다
• 따라서 JPA/하이버네이트에서는 EAGER 대신 FetchType.LAZY를 기본으로 권장한다

N+1 문제의 발생 원인 및 FetchType과의 관계

N+1 문제는 기본적으로 FetchType.LAZY일 때 흔히 발생하지만 FetchType.EAGER에서도 발생할 수 있다.

1. LAZY일 때 : 학생 목록 테이블을 가져오는 메인 쿼리가 실행된다 → 개발자가 테이블 내 모든 학생에 접근하려 하면 JPA는 각 엔티티마다 연관된 데이터를 가져오기 위해 N번의 추가 쿼리를 실행한다 → 총 1 + N 번의 쿼리가 발생한다
2. EAGER일 때 : FetchType.EAGER는 연관된 데이터를 즉시 로딩하지만 JPA 구현체(하이버네이트)는 이 즉시 로딩을 처리할 때 내부적으로 N+1 방식을 사용한다. 즉, 위의 LAZY와 완전히 동일한 문제가 발생한다 → FetchType.EAGER은 N+1 문제의 해결책이 아니며, 오히려 개발자의 의도와 달리 대량의 쿼리가 발생하는 상황을 만들 수 있다!

FATCH JOIN

• FATCH JOIN은 N+1 문제의 근본적인 해결책으로 개발자가 직접 JPQL/QueryDSL로 JOIN FETCH 구문을 작성하여 쿼리를 제어한다
• 필요한 테이블의 정보들을 join 후 가져옴으로써 1번의 쿼리로 필요한 모든 정보를 가지고 올 수 있다

@EntityGraph

• @EntityGraph를 사용하면 개발자가 직접 JPQL에서 JOIN FETCH 구문을 작성하지 않아도 JPA 구현체(하이버네이트)가 @EntityGraph의 정의를 보고 가장 효율적인 쿼리(대부분 JOIN을 사용한 쿼리)를 자동으로 생성하고 실행해준다
• JPQL 쿼리를 직접 작성할 필요 없이 메소드 이름이나 어노테이션으로 N+1 문제를 해결할 수 있어 코드가 깔끔해진다
• 그러나 복잡한 조건 등의 동적 쿼리에서는 FETCH JOIN을 이용해 쿼리문을 직접 작성하는 것이 더 적합할 수 있다

결론 : N+1 문제를 해결하기 위해서는 FetchType.LAZY를 기본으로 사용하고 특정 상황에서 많은 양의 연관 데이터가 필요할 때 FETCH JOIN 또는 @EntityGraph를 사용하여 쿼리를 최적화하여야 한다

casecade 설정

• 양방향 매핑을 할 경우 cascade 설정을 할 수 있다
• cascade는 한 테이블을 수정, 삭제 할 때 연관된 모든 테이블을 함께 수정, 삭제하는 기능이다
• cascade 설정에서 선택 가능한 옵션은 아래와 같다
  • ALL: 모든 cascade 작업 전파
  • DETACH: 엔티티 분리 시, 연관 엔티티도 분리
  • MERGE: 엔티티 병합 시, 연관 엔티티도 병합
  • PERSIST: 엔티티 저장 시, 연관 엔티티도 저장
  • REFRESH: 엔티티 새로고침 시, 연관 엔티티도 새로고침
  • REMOVE: 엔티티 삭제 시, 연관 엔티티도 삭제
• 단방향 매핑에선 사용할 수 없으며 이 경우 서비스 클래스에서 연관된 데이터들을 직접 지워주는 방식을 사용해야 한다

계층형 구조 vs 도메인형 구조

계층형 구조

• 도메인, 레파지토리, 서비스, 컨트롤러로 계층을 나누는 전통적인 방식
• 새로운 도메인 추가 시 모든 계층에 추가 파일이 필요하다
• 같은 역할을 하는 파일들이 한 폴더에 모여있다
• 구조가 단순하고 이해하기 쉽다
• 작은 프로젝트에 적합하다

도메인형 구조

• 어플리케이션의 핵심 업무 단위인 도메인, 즉 명사를 기준으로 나누는 방식
• 새로운 도메인 추가 시 해당 도메인의 폴더만 수정하면 되므로 모듈화에 유리하다
• 한 도ㅁ메인의 모든 관련 파일들이 한 폴더에 모여 있다
• 결합도가 낮고 응집도가 높다
• 대규모/복찹한 프로젝트에 적합하다
• 만약 어떤 도메인에 문제가 생기거나 수정이 필요하면 해당 도메인의 폴더만 열어 모든 관련 파일을 찾을 수 있다 → 유지보수에 용이