최근 코드 리팩토링을 하면서, 이미지 파일 업로드 기능 추가를 위해 기존 @RequestBody 에서 @ModelAttribute 로 바꿔 사용했다.
@PostMapping("/todos")
public ResponseEntity<CardResponseDto> createTodoCard(
@ModelAttribute @Valid CardPostRequestDto cardPostRequestDto,
@AuthenticationPrincipal UserDetailsImpl userDetails) {
CardResponseDto responseDto = cardService.createTodoCard(cardPostRequestDto,
userDetails.getUser());
return ResponseEntity.status(201).body(responseDto);
}
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor
public class CardPostRequestDto {
@NotEmpty
private String title;
@NotEmpty
private String content;
private MultipartFile file;
}
하지만 계속 테스트 코드를 돌리는데, 오류가 나는 것이다.
이게 왜 이러지? 싶었는데 ModelAttribute를 쓸 거면 NoArg + Setter를 쓰거나
AllArg 로만 사용하라고 하는 것이다.
@Getter
@Builder
@AllArgsConstructor
public class CardPostRequestDto {
@NotEmpty
private String title;
@NotEmpty
private String content;
private MultipartFile file;
}
ModelAttribute에 대해 정확히 알지는 못하는 상태로 사용했던 것이긴 하나, 왜 이렇게 만들어 놨는지 이해가 안됐다.
이해가 안 되면 내가 만들면 되잖아??
라고 생각이 들긴 하나, 아직 그럴 수준까진 안 돼서.. 할 말은 없다
내가 저 기능을 만든 개발자의 성향에 의존을 하게 되는 이상한 현상이 일어나자
의존에 대해 고민을 해보게 됐다.
최근에 작성한 글들을 보면 되게 의존성이 짙은 것들을 많이 사용해봤다.
그러면서 개발의 편의성을 느끼긴 하나, 내가 원리를 정확히 모르고 사용법만 아는 상태에서 사용한다면, 나는 대체 뭘 배우는 걸까 생각이 들었다.
그리고 의존성이 너무 짙고, 리팩토링을 하면서 패턴의 변경이 엄청나게 많은 레거시 코드를 바꿔야되는 되게 귀찮은 일이라는 것을 느꼈다.
그래서 의존성이 짙은 것에 대해 조금 더 고민해봐야하는 시간을 가져야 될 거 같다
'TIL' 카테고리의 다른 글
TIL 2023-12-27 팀 프로젝트 위치 변경 로직 구현 - 삽입 정렬 (0) | 2023.12.28 |
---|---|
TIL 2023-12-26 @ColumnDefault 과 Nullable (0) | 2023.12.26 |
TIL 2023-12-21 @Modifying QueryDsl에도 적용이 될까? (0) | 2023.12.21 |
TIL 2023-12-20 스프링 해시태그 기능 구현 (0) | 2023.12.20 |
TIL 2023-12-19 @WebMvcTest 와 Application JPAQueryFactory Bean 등록 오류 (2) | 2023.12.19 |