💡 개요
MultipartFile을 Controller에서 받기 위해선 Setter가 필요하다.
@Setter
public class ProductRegisterRequest {
private String productName;
private String productContent;
private int price;
private MultipartFile file;
...
}
@RestController
@RequiredArgsConstructor
@RequestMapping("/api/v1/products")
public class ProductController {
private final ProductService productService;
@PostMapping("/register")
public ResponseEntity<CommonResponse> registerProduct(@ModelAttribute ProductRegisterRequest request,
@AuthenticationPrincipal UserDetails userDetails) {
productService.registerProduct(request.toService(userDetails.getUsername()));
return ResponseEntity.ok().body(new CommonResponse(HttpStatus.OK.value(), "제품 등록 완료"));
}
...
}
왜 그럴까?
📕 MultipartFile
MultipartFile란 Spring에서 파일 데이터를 다룰 때 사용되는 인터페이스이다.
클라이언트가 파일을 서버로 전송하면 핸들러가 해당 파일을 쉽게 다루기 위해 사용된다.
MultipartFile에서 제공되는 메서드는 다음과 같다.
메서드명 | 내용 |
getName() | 파라미터의 이름을 반환 |
getOriginalFilename() | 클라이언트가 업로드한 원본 파일명 반환 |
getContentType() | 파일의 MIME 타입 반환 |
isEmpty() | 파일이 비어있는지 확인 |
getSize() | 파일 크기(byte) 반환 |
transferTo(File dest) | 파일을 지정한 경로로 전송 |
📕 MultipartFile에 Setter가 필요한 이유
Spring에서 파일을 요청으로 받을 땐 Spring MVC의 MultipartResolver를 사용한다.
MultipartResolver은 디스패처 서블릿에 속하기 때문에 컨트롤러에게 MultipartFile 타입으로 변환된 형태로 전달된다.
그래서 보통 컨트롤러에서 직접 MultipartFile을 받으면 Setter 같은 설정 메서드 없이 받을 수 있다.
@PostMapping("/upload")
public String handleFileUpload(@RequestParam("file") MultipartFile file) {
// 파일 처리 로직
return "success";
}
하지만 아래 예시 코드를 보다시피 DTO 형태로 전달받는 경우는 얘기가 다르다.
@Setter
public class ProductRegisterRequest {
private String productName;
private String productContent;
private int price;
private MultipartFile file;
...
}
일반적으로 MultipartFile은 Setter 기반 바인딩을 사용하기 때문에 DTO를 사용할 경우 Setter 설정을 해줘야 한다.
결국 이유는 MultipartFile은 기본적으로 Setter 기반 바인딩을 사용해서 이다..
허무하네..
'개발 일기' 카테고리의 다른 글
[개발 일기] 2025.03.20 - 에러 로그를 찍어도 되나? (Feat : 시큐어 코딩) (0) | 2025.03.20 |
---|---|
[개발 일기] 2025.03.19 - @Valid (0) | 2025.03.19 |
[개발 일기] 2025.03.17 - Code Kata (0) | 2025.03.17 |
[개발 일기] 2025.03.16 - Session.invalidate() (0) | 2025.03.16 |
[개발 일기] 2025.03.15 - LATERAL JOIN (0) | 2025.03.15 |