7주차 과제 구현

[dietken1]

🔥Pull requests

👷 과제 구현

필수과제

• 앱잼 신청
• 기획경선 및 밋업 참여
• 댓글 기능 추가

선택과제

• 캐싱으로 성능 최적화
• 대용량 데이터 처리 및 정렬 최적화
• 인프라 설계 시각화
• 테스트 코드 도입
• 기능 디벨롭 및 성능 개선

구현한 내용에 대해서 설명해주세요

1. 댓글(Comment) CRUD 기능 구현

• 엔티티 설계

  • Comment 엔티티 생성
  • Article, Member와의 다대일 양방향 연관관계 설정
  • JPA Auditing을 활용한 생성/수정 시간 자동 관리

• API 엔드포인트

  • POST /api/v1/comments - 댓글 생성
  • GET /api/v1/comments/{id} - 댓글 조회
  • PATCH /api/v1/comments/{id} - 댓글 수정
  • DELETE /api/v1/comments/{id} - 댓글 삭제

• 서비스 로직

  • 댓글 생성 시 Article과 Member 존재 여부 검증
  • 트랜잭션 관리를 통한 데이터 정합성 보장
  • 비즈니스 예외 처리

2. Article 조회 API 응답 필드 수정

• ArticleResponse 구조 변경

  • 기존 응답에 comments 필드 추가
  • 아티클 조회 시 해당 아티클에 달린 댓글 목록도 함께 반환
  • Nested DTO 구조: Comment(commentId, memberId, comment)

• N+1 문제 해결

  • Fetch Join을 활용한 Article-Comment 연관관계 최적화
  • 아티클 조회 시 댓글 데이터를 한 번의 쿼리로 가져옴

구현하며 고민했던 내용을 적어주세요 (사소한 것도 좋아요)

JPA에서의 올바른 업데이트 방법

댓글 수정 및 회원 수정 기능을 구현하면서 JPA의 업데이트 메커니즘에 대해 깊이 고민했습니다.

고민한 내용:

1. 변경 감지(Dirty Checking) vs 명시적 save() 호출

   • JPA는 영속 상태의 엔티티 변경을 자동 감지하여 UPDATE 쿼리를 생성합니다
   • 트랜잭션 범위 내에서 엔티티를 조회 후 값을 변경하면, save() 없이도 자동으로 DB에 반영됩니다

2. 업데이트 로직의 위치

   • 엔티티 내부에 update() 메서드를 두어 응집도를 높였습니다
   • 서비스 계층에서 setter를 직접 호출하지 않고 도메인 메서드를 호출하는 방식을 선택했습니다

3. 트랜잭션 범위의 중요성

   • @Transactional 어노테이션이 없으면 변경 감지가 작동하지 않습니다
   • 읽기 전용 트랜잭션(readOnly = true)에서는 변경 감지가 동작하지 않음을 확인했습니다

결론

이번 과제에서는 변경 감지(Dirty Checking) 방식을 선택했습니다.

선택 이유

1. JPA의 철학에 부합: 영속성 컨텍스트가 엔티티의 생명주기를 관리
2. 코드의 간결성: 불필요한 save() 호출 제거
3. 도메인 주도 설계: 엔티티 내부에 update() 메서드를 두어 응집도 향상
4. 성능 최적화: 변경된 필드만 UPDATE