Conversation
|
일단 모든 DTO를 Member 패키지 쪽에 몰빵해서 구현한 것 같은데, 이러면 도메인 기반 패키지 구조를 만든 의미가 사라지니까, 각각 알맞은 패키지 쪽 DTO에다가 넣어주는 게 좋을 것 같아. 컨트롤러도 MemberController랑 UserController 2개가 있는데, 필요한 게 아니라면 하나는 지우는 게 나중에 안 헷갈릴 것 같아! |
gyeonseo
left a comment
gyeonseo
left a comment
There was a problem hiding this comment.
링크 이번 미션하면서 우당탕했던 과정을 미션 기록에 남겨준것도 좋다 ㅎㅎ
미션이랑 리뷰 도메인은 왜 안해줬어!! 앞으로 남은 미션도 다 5주차 미션에서 이어나가는 내용들이라 6주차 전까지 꼭.꼭!! 진행해줘 6주차 파이팅이야~
| private final T result; | ||
|
|
||
| // 성공 | ||
| public static <T> ApiResponse<T> onSuccess(BaseSuccessCode code, T result) { |
| public class GeneralExceptionAdvice { | ||
|
|
||
| // 우리가 만든 예외 처리 | ||
| @ExceptionHandler(ProjectException.class) |
There was a problem hiding this comment.
맞아 우리가 만든 도메인 예외들이 ProjectException을 상속해서 요기 핸들러에서 잡히는거지! 굿굿이야
| @RequestBody UserJoinRequestDTO request | ||
| ) { | ||
|
|
||
| UserJoinResponseDTO response = new UserJoinResponseDTO(1L); |
There was a problem hiding this comment.
response dto 생성하는 부분은 나중에 서비스로직으로 옮겨야겠지?!
|
|
||
| // 리뷰 작성 | ||
| @PostMapping("/{userId}/reviews") | ||
| public ApiResponse<String> writeReview( |
There was a problem hiding this comment.
응답을 단순히 String으로 내려주는건 비추야.
"리뷰 작성 완료"라는 코멘트는 이미 성공코드 내에서 msg 에서 내려주잖아? 성공 코드를 Result 를 통해서 또 한 번 내려주는 느낌이야.
리뷰 작성에 대한 결과가 딱히 없다고 생각할수도 있지만,
리뷰 작성이 결국 새로운 리뷰 생성이잖아? 신규 리뷰의 아이디가 프론트에서 필요할수도 있지. 요런 생각을 해봤으면 좋겠다~
만약 정말 내려줄 데이터가 없으면 아예 ApiResponse 로 설계하면 돼~
|
|
||
| // 미션 목록 조회 | ||
| @GetMapping("/{userId}/missions") | ||
| public ApiResponse<String> getMissions( |
There was a problem hiding this comment.
미션 목록은 더더욱 String이 아니라 미션 목록에 대한 response dto 로 설계해야겠지??!
| import lombok.Getter; | ||
|
|
||
| @Getter | ||
| public class UserJoinRequestDTO { |
There was a problem hiding this comment.
요게 결국 MemberReqDto 내부에 들어가면 될것같은데 링크?
지금이야 dto 개수가 적으니까 이렇게 하나씩 따로 클래스 생성이 가능하지만.. 나중에는 dto 가 정말 많이 늘어나!! 이렇게 관리하기는 힘들어.
키워드 통해서 record랑 static class에 대해 조사했잖아? 그 내용을 바탕으로 여기 부분 다시 설계해보면 좋겠다!
4 participants
📂 관련 이슈
🛠️ 작업 사항
📸 관련 이미지 (스크린샷 또는 동영상)
💬 기타 설명