Validation 검증 - BindingResult 사용

 

이전 글로 BindingResult에 대해 알아보았습니다.

Validation 검증 - BindingResult란?

이번 글로 BindingResult의 사용에 대해 알아봅시다.

 

---

 

BindingResult 사용

1. BindingResult가 사용되는 위치
2. FieldError
3. ObjectError
4. BindingResult에 검증 오류를 담는 3가지 방법

을 다룹니다.

 

---

 

BindingResult가 사용되는 위치

BindingResult는 @ModelAttribute의 객체 다음에 와야 합니다.

내부에서 파라미터 자리 정보를 사용하여 Validation을 적용할 객체를 정하기 때문입니다.

개인 프로젝트에 사용된 BindingResult 입니다. @ModelAttribute가 적용된 LoginDto 객체 다음으로 BindingResult 객체가 오고 있습니다.

BindingResult의 addError(...) 사진입니다. 해당 사진은 개발자가 직접 넣는 메서드이지만, 스프링이 자동으로 넣어주는 방법도 있습니다. 주목해야하는 부분은 ObjectError, FieldError를 BindingResult에 담는다는 사실입니다.

 

---

 

FieldError

필드에 오류가 있으면

 FieldError를 생성해서 BindingResult에 담습니다.

FieldError의 생성자 입니다.

• objectName : 오류가 발생한 객체 이름
• field : 오류 필드
• rejectedValue : 사용자가 입력한 값(거절된 값)
• bindingFailure : 타입 오류 같은 바인딩인지, 검증 실패인지 구분 값
• codes : 메시지 코드 (message.properties의 메시지라고 이해하시면 됩니다.)
• arguments : 메시지에서 사용하는 인자 (message.properties에서도 {0} {1} 이런 식으로 인자를 받았죠?)
• defaultMessage : 기본 오류 메시지

 

ObjectError

특정 필드를 넘어서는 오류가 있으면
 ObjectError를 생성해서 BindingResult에 담습니다.

ObjectError 생성자 입니다.

• FieldError는 ObejctError를 상속받습니다. LSP(리소코브 치환 원칙)에 따라 FieldError는 ObjectError의 확장이고 ObjectError의 규약과 관례를 따릅니다.
• 즉 파라미터의 의미는 FieldError와 같습니다.

 

---

 

BindingResult에 검증 오류를 담는 3가지 방법

1. @ModelAttribute의 객체에 타입 오류 등으로 바인딩이 실패하는 경우
    스프링이 FieldError를 생성해서 BindingResult에 넣어줍니다.
2. 개발자가 FieldError를 생성하고
    직접 BindingResult에 넣어줍니다.
3. Validator를 사용합니다.

 

Validator 란?

체계적인 검증 기능 도입이 가능합니다.
Validator Interface를 상속받는 MyValidator를 만들 수 있습니다.
코드로 직접 적용과 @Validated 애노테이션으로 선언하여 적용할 수 있습니다.
Validator 내용은 추 후 따로 포스팅합니다.

 

BindingResult는 Error Interface를 상속받고 있습니다.
Error Interface는 단순한 오류 저장과 조회 기능을 제공합니다.

관례상 BindingResult를 많이 사용하고 있으며 추가적인 기능들도 제공하므로
  Error와 BindingResult 둘 중 무엇을 사용할지 고민 중이시라면
   BindingResult를 사용하는 것이 좋다고 생각합니다.

 

---

 

다음 글로 사용자가 입력한 값(거절된 값)을 보존하는 방법과 오류 메시지를 남기기에 대해 알아봅시다.

Validation 검증 - 사용자 입력 보존과 오류 메시지 남기기