[F팀 장주리] 백엔드 API 과제 제출 - #7
Conversation
jinu0328
left a comment
There was a problem hiding this comment.
과제 수행 고생 많으셨습니다!
몇가지 피드백을 남겨두었으니 참고해주시면 좋을 것 같습니다 👍
| @DeleteMapping("/{id}") | ||
| public ResponseEntity<Map<String, Object>> deleteTask(@PathVariable Long id){ | ||
| Optional<Task> task = taskRepository.findById(id); | ||
| if (task.isPresent()) { |
There was a problem hiding this comment.
여기서 taskRespository를 활용하기에 controller에서도 tastRepository의 의존성을 갖게 된 것으로 보입니다. 이미 taskService가 taskRespository에 대한 의존성을 가지고 있는 만큼 controller에서 중복된 의존성을 가질 필요는 없다고 생각합니다. task가 존재하는 지 확인하는 로직도 service 메서드 내로 옮긴다면 controller에서 service에 대한 의존성만 가져도 충분할 것 같습니다 😄
There was a problem hiding this comment.
dto를 잘 구성해주신 만큼 엔티티 클래스에 직접 get 메서드를 적용하기보다 dto 변환 메서드를 추가해줌으로써 엔티티 객체의 안정성을 더 보장해 줄 수 있을 것 같습니다.
ex)
public TaskResponseDto toDto() {
return new TaskResponseDto(id, title, isDone)
}
There was a problem hiding this comment.
API 응답의 ResponseEntity 구조가 거의 동일하게 반복되고 있습니다. status, message, data를 사용하는 구조를 반복적으로 작성하는 대신, 이를 하나의 공통 응답 객체로 관리하면 코드의 재사용성과 가독성을 크게 향상시킬 수 있을 것 같습니다. 현재 main 브랜치에도 그러한 방식으로 코드가 작성되어있으니 참고해주시면 좋을 것 같습니다! 👍
No description provided.