작성일: 2023.06.19(월)

KT AIVLE AI 개발자 트랙 3기 과정의 마지막인 빅프로젝트를 진행하고 있습니다.

Daily Scrum

내 역할, 협업 내용, 나머지는 팀원 담당

What did you do yesterday?

• spring JPA 활용 실습
• 로그인, 회원가입 설계 및 구현

What will you do today?

• 프로젝트 노션 정리
• 게시판 API 설계
• 게시판 FE 설계 및 구현

Are there any impediments in your way?

• 오늘 4명의 팀원이 개인사정으로 참여 어려웠음

What I did today

JPA 활용1

섹션 2. 도메인 분석 설계

• 구현할 기능과 요구사항을 정리
• DB 테이블, 컬럼 이름: '(대문자 or 소문자) + 언더스코어'를 주로 사용. 일관성이 중요함
• @Enumerated(EnumType.종류)에서 종류는 STRING 사용 권장(ORDINAL은 절대 쓰지 않기)

연관관계 매핑

• 'OneToMany' 관계일 때, 연관관계의 '주인'이 필요
• 외래키는 일반적으로 'Many'쪽에 외래키를 두며, 외래키가 있는 쪽이 주인이 되는 것이 좋음
• '주인'이 비즈니스상 우위에 있다는 뜻이 아님.
• '주인' 설정은 외래키 관리 주체를 정하는 용도

연관관계의 주인

• 양방향 연결 상태에서 값이 변경될 때, 어디를 바꿔야 할지 JPA가 알아야 함
• 객체는 변경 포인트가 두 곳이지만, 테이블은 'FK 하나'만 변경하면 되도록 JPA에서 규약을 설정함
• 'FK 하나'를 설정하는 것이 '주인'을 정하는 것
• 주인은 그대로 두고, 반대쪽 '@OneToMany'를 '@OneToMany(mappedBy="필드")'로 설정하면 됨
• 해석: 주인 쪽에 있는 '필드'에 의해서 매핑이 이루어짐 -> 읽기전용 상태

OneToOne 관계

• 양쪽 아무곳에나 FK를 두어도 괜찮으나, access가 많이 이루어지는 곳에 두는 것이 일반적

ManyToMany 관계

• 실무에서는 거의 사용하지 않음
• 관계형 데이터베이스에서 일반적인 설계로는 '다대다' 관계는 사용X
  -> 매핑 테이블을 이용하여 '일대다, 다대일' 관계로 나눠야 함

상속관계 매핑

• 상속관계 전략을 지정하기 위해, 부모 클래스에 전략을 지정해야 함
• JOINED: 가장 정교화된 스타일
• SINGLE_TABLE: 한 테이블에 다 넣는 스타일
• TABLE_PER_CLASS: 각각 모두 테이블로 만드는 스타일
• '@Inheritance(strategy = InheritanceType.전략)'
• (+ '@DiscriminatorColumn(name = "dtype"))
• (자식에서) '@DiscriminatorValue(이름)'

엔티티 클래스 개발

• 엔티티 설계와 구동 및 생성 확인을 자주 반복해주는 것이 좋음
• @Getter는 열어두어도 괜찮으나, @Setter는 필요한 경우를 제외하고는 사용하지 않는 것을 추천
• @Setter가 열려있으면 변경 포인트가 많아져서 언제, 어디서 수정되었는지 알기 어려움(유지보수 난이도 UP)
• 모든 연관관계는 지연로딩으로 설정
  • 즉시로딩(EAGAR): 엔티티 조회 시 모든 연관된 것들을 한번에 조회. 예어떤 SQL이 실행될 지 추적이 어려움. (N+1)문제 발생
  • (N+1)문제: 1개의 쿼리 결과가 N개일 때, N개의 연관 쿼리가 더 생기는 문제
  • 연관된 데이터를 조회 시, Fetch Join이나 엔티티 그래프 기능을 사용
  • '@XToOne' 관계는 '즉시로딩'이 디폴트이므로, 지연로딩으로 직접 설정해주어야 함
• 컬렉션은 필드에서 바로 초기화 하는 것이 'null 안정성'면에서 안전
• 테이블, 컬럼명 생성 전략
  • 스프링부트에서 'SpringPhysicalNamingStrategy'를 사용
  • 카멜케이스를 언더스코어로, .(점)을 언더스코어로, 대문자를 소문자로 변경해줌

섹션 3. 애플리케이션 구현

애플리케이션 아키텍처

• 계층형 아키텍처
• Controller, Web: 웹 계층. 클라이언트 요청을 받고, 서비스에 처리 요청. 클라이언트에 응답
• Service: 비즈니스 로직(save, find, cancel, join 등), 트랜잭션 처리
• Repository: JPA를 직접 사용하는 계층. 엔티티 매니저 사용
• Domain: 엔티티가 모여있는 계층. 다른 계층은 Domain을 참조하도록 설계
• 권장 개발 순서: Domain -> Exception -> Repository -> Service -> Web

섹션 4-6. 도메인 개발

• JPQL: 테이블이 대상인 SQL과 달리, JPQL은 엔티티를 대상으로 함

• @Transactional(readOnly = true): JPA가 '조회'하는 곳에서는 성능을 최적화함. '쓰기'에는 넣지 않아야 함

• public Member findOne(Long memberId)

  • Member: 리턴 타입
  • findOne: 메서드명
  • Long: 인자 타입
  • memberId: 인자 이름

• 생성자 주입

  • 필드 주입이나, setter 주입보다 생성자 주입 방식을 권장
  • 변경 불가능한 안전한 객체 생성
  • @RequiredArgsConstructor: final이 있는 필드만으로 생성자를 만들어주는 역할
  • 스프링 데이터 JPA를 사용하면 'EntityManager'도 주입 가능

• 테스트

  • @RunWith(SpringRunner.class): 스프링과 테스트 통합
  • @SpringBootTest: 스프링 부트 띄우고 테스트(없으면 @AutoWired 실패)
  • @Transactional: 반복 가능한 테스트 지원
  • 테스트를 완전히 격리된 환경에서 진행하기 위해 메모리DB 사용 권장

• 엔티티 안에 비즈니스로직을 넣는 것이 좋음(객체지향적, 응집력 상승)

• this 사용

  • 소유를 강조할 때 혹은 이름이 중복될 때 주로 사용
  • 이외의 경우에는 안써도 무방(why? IDE가 색칠해줌)

• 생성스타일 제약

  • 생성로직을 만들고 제약을 두지 않으면, 유지보수가 어려워짐
  • 'protected' 설정을 권장
  • lombok에서 @NoArgsConstructor(access = AccessLevel.PROTECTED) 사용하면 됨

• 도메인 모델 패턴

  • 엔티티에 핵심 비즈니스로직을 두고 이를 호출하는 방식
  • 서비스 계층은 엔티티에 필요한 요청을 위임하는 역할

• 트랜잭션 스크립트 패턴

  • 엔티티에 비즈니스 로직이 거의 없음
  • 서비스 계층에서 대부분의 비즈니스 로직을 처리

섹션 7. 웹 계층 개발

• 변경감지와 병합

  • 엔티티가 영속상태로 관리됨 -> 값이 바뀌면 JPA가 트랜잭션 커밋 시점에 변경 내용을 감지하여 DB에 반영함
  • Dirty Checking: 변경 내용을 감지하는 것

• 준영속 엔티티

  • 영속성 컨텍스트가 더 이상 관리하지 않는 엔티티
  • JPA를 통해 DB에 들어갔다가 다시 임의로 만들어낸 엔티티 -> 기존 식별자가 존재
  • JPA가 관리를 하지 않으므로, 업데이트의 근거와 명분이 없음

• 준영속 엔티티 수정법

  • 변경 감지(더 나은 방법): 영속성 컨텍스트에서 엔티티 재조회 후 수정
    
  • 병합: 준영속 상태의 엔티티를 영속 상태로 변경하여 수정

꿀팁

• cmd + opt + N: lnline Variable로 변경
• cmd + opt + V: 자동으로 변수 추출

마치며

JPA 강의를 절반 듣고, API 내용도 어느정도 들은 상태이다.
API 구현할 내용이 어렵지 않으므로 강의를 들으면서 내일부터는 본격적인 구현을 시작해보려고 한다.
기초가 거의 없는 상태에서 구현하는 방법만 들은거라서 JPA 기본 강의도 같이 들을 예정이다.