<aside> 📖 Validation

</aside>

정리

1. Map 에 검증 오류 정보를 담아 뷰로 리턴 → 타입 검증 불가 등 여러 문제점 발생
2. 스프링이 제공하는 BindingResult 에 FieldError , ObjectError 생성하여 오류 정보 담아 리턴
   • BindingResult 가 있으면 타입 오류 발생 시 400 오류 나지 않고 컨트롤러도 정상 호출됨
   • BindingResult 없으면 타입 오류 발생 시 400 오류 발생, 오류 페이지로 이동
3. FieldError 와 ObjectError 의 생성자 대신 rejectValues(), reject() 사용하여 검증 오류 처리
4. 메시지 내용을 errors.properties 메시지 파일로 별도 관리
   • 구체 → 범용
   • 스프링이 생성해주는 메시지 코드 처리
5. Validator 인터페이스 구현하여 검증 로직 별도 분리
   • 빈 주입 통해 직접 validate() 호출
   • 스프링이 제공하는 WebDataBinder + @Validated 통해 호출

⇒ 최종 코드 정리

@InitBinder
public void init(WebDataBinder dataBinder) {
		dataBinder.addValidators(itemValidator);
}

@PostMapping("/add")
public String addItemV6(@Validated @ModelAttribute Item item
											, BindingResult bindingResult
											, RedirectAttributes redirectAttributes) {
		if (bindingResult.hasErrors()) {
				return "validation/v2/addForm";
		}

		//성공 로직
		Item savedItem = itemRepository.save(item);
		redirectAttributes.addAttribute("itemId", savedItem.getId());
		redirectAttributes.addAttribute("status", true);
		return "redirect:/validation/v2/items/{itemId}";
}

검증 방식

• 클라이언트 검증 : 조작 가능, 보안에 취약

• 서버 검증 : 즉각적인 고객 사용성 부족

  • 컨트롤러 : HTTP 요청이 정상인지 검증 필요

  → 적절히 섞어서 사용하되 최종적으로 서버 검증 필수

  (API 방식 사용 시 API 응답 결과에 검증 오류를 남겨줘야 함)

검증 직접 처리

• addITem() 수정 코드