Conversation
|
|
||
| @NotNull(message = "location cannot be null") | ||
| private int location; | ||
|
|
There was a problem hiding this comment.
통상적으로 응답DTO에서는 유효성 검증을 하지 않습니다! 정말 필요한 것이 아니라면 서비스 로직에서 에러 핸들링을 하는 것이 좋을 것 같습니다!
There was a problem hiding this comment.
유효성 검증 부분 삭제했습니다!
|
|
||
| @Getter | ||
| @NoArgsConstructor | ||
| public class ImageResponseDTO { |
There was a problem hiding this comment.
그리고 클래스 명의 DTO는 컨벤션에따라 파스칼 케이스를 사용하고자 본인 담당 DTO를 Dto로 수정해주시면 감사하겠습니다!
There was a problem hiding this comment.
Invitation 관련, Account 관련, Image 관련 DTO 모두 DTO -> Dto로 변경 완료했습니다!
There was a problem hiding this comment.
혹시 겹치는 부분있으면 환이님한테도 꼭 알려주세요! 컨플릭트 납니다
| @PathVariable Long invitationId){ | ||
| return ResponseEntity.status(HttpStatus.OK) | ||
| .body(GlobalResponseDto.success(invitationService.getInvitation(invitationId))); | ||
| } |
There was a problem hiding this comment.
추후 비회원의 조회도 및 URL 생성 api까지 잘 부탁드리겠습니다! 그리고 본인 청첩장 조회의 역할이라면 Member 객체까지 활용하여 멤버와 청첩장 id 가 일치하는 것을 레포지토리에서 조회하는 것이 데이터의 무결성을 보장하기에 좋다고 생각하는데 이 부분에 대해 어떻게 생각하시나요?
There was a problem hiding this comment.
좋은 생각인 것 같습니다! 추후 member 객체 활용하는 부분 추가하며 한꺼번에 추가하도록 하겠습니다!
|
문제될 부분 없어 보입니다! 고생하셨습니다 |
개요
청첩장 조회 (정보, Account 리스트, 사진 url 리스트)
PR 유형
어떤 변경 사항이 있나요?
PR Checklist
PR이 다음 요구 사항을 충족하는지 확인하세요.
📣 To Reviewers
외부인이 조회할 수 있는 api는 따로 제작 예정
에러 핸들링 마지막에 한 번에 할 예정