BindingResult2
스프링이 제공하는 검증 오류를 보관하는 객체이다. 검증 오류가 발생하면 여기에 보관하면 된다.
BindingResult 가 있으면 @ModelAttribute 에 데이터 바인딩 시 오류가 발생해도 컨트롤러가 호출된다!
@ModelAttribute에 바인딩 시 타입 오류가 발생하면?
BindingResult 가 없으면 400( bad request ) 오류가 발생하면서 컨트롤러가 호출되지 않고, 오류 페이지로 이동한다.
BindingResult 가 있으면 오류 정보( FieldError )를 BindingResult 에 담아서 컨트롤러를 정상 호출한다.
BindingResult에 검증 오류를 적용하는 3가지 방법
- @ModelAttribute 의 객체에 타입 오류 등으로 바인딩이 실패하는 경우 스프링이 FieldError 생성해서 BindingResult 에 넣어준다.
- 개발자가 에러 객체를 직접 생성하여 넣어준다. (비지니스 검증 로직)
- Validator 사용
주의
BindingResult 는 검증할 대상 바로 다음에 와야한다. 순서가 중요!
ex. (@ModelAttribute Item item, BindingResult bindingResult)
BindingResult 는 Model에 자동으로 포함된다.
BindingResult와 Errors
org.springframework.validation.Errors
org.springframework.validation.BindingResult
BindingResult 는 인터페이스이고, Errors 인터페이스를 상속받고 있다.
실제 넘어오는 구현체는 BeanPropertyBindingResult 라는 것인데, 둘 다 구현하고 있으므로 BindingResult 대신에 Errors 를 사용해도 되지만 Errors 인터페이스는 단순한 오류 저장과 조회 기능만을 제공한다.
BindingResult 는 여기에 더해서 추가적인 기능들을 제공한다. addError() 도 BindingResult 가 제공하므로 여기서는 BindingResult 를 사용하자. 주로 관례상 BindingResult 를 많이 사용한다.
정리
BindingResult , FieldError , ObjectError 를 사용해서 오류 메시지를 처리하는 방법을 알아보았다.
그런데 오류가 발생하는 경우 고객이 입력한 내용이 모두 사라진다.
FieldError, ObjectError
목표
사용자 입력 오류 데이터가 화면에 남도록 하자.
FieldError 생성자 FieldError 는 두 가지 생성자를 제공한다.
public FieldError(String objectName, String field, String defaultMessage);
public FieldError(String objectName, String field, @Nullable Object rejectedValue, boolean bindingFailure,
@Nullable String[] codes, @Nullable Object[] arguments, @Nullable String defaultMessage)
파라미터 목록
objectName : 오류가 발생한 객체 이름
field : 오류 필드
rejectedValue : 사용자가 입력한 값(거절된 값)
bindingFailure : 타입 오류 같은 바인딩 실패(true)인지, 검증 실패(false)인지 구분 값
codes : 메시지 코드
arguments : 메시지에서 사용하는 인자
defaultMessage : 기본 오류 메시지
ObjectError 도 유사하게 두 가지 생성자를 제공한다. 코드를 참고하자.
오류 발생시 사용자 입력 값 유지
사용자의 입력 데이터가 컨트롤러의 @ModelAttribute 에 바인딩되는 시점에 오류가 발생하면 모델 객체에 사용자 입력 값을 유지하기 어렵다. 예를 들어서 가격에 숫자가 아닌 문자가 입력된다면 가격은 Integer 타입이므로 문자를 보관할 수 있는 방법이 없다. 그래서 오류가 발생한 경우 사용자 입력 값을 보관하는 별도의 방법이 필요하다. 그리고 이렇게 보관한 사용자 입력 값을 검증 오류 발생시 화면에 다시 출력하면 된다.
FieldError 는 오류 발생시 사용자 입력 값을 저장하는 기능( rejectedValue ) 을 제공한다.
타임리프의 사용자 입력 값 유지
th:field="*{price}"
타임리프의 th:field 는 매우 똑똑하게 동작하는데, 정상 상황에는 모델 객체의 값을 사용하지만, 오류가 발생하면 FieldError 에서 보관한 값을 사용해서 값을 출력한다.
스프링의 바인딩 오류 처리
타입 오류로 바인딩에 실패하면 스프링이 자동으로 FieldError 를 생성하면서 사용자가 입력한 값을 넣어둔다. 그리고 해당 오류를 BindingResult 에 담아서 컨트롤러를 호출한다. 따라서 타입 오류 같은 바인딩 실패시에도 사용자의 오류 메시지를 정상 출력할 수 있다.
오류 코드와 메시지 처리1
FieldError , ObjectError 의 생성자는 codes , arguments 를 제공한다.
이것은 오류 발생시 오류 코드로 메시지(MessageSource) 를 찾기 위해 사용된다.
errors 메시지 파일 생성
오류 메시지를 구분하기 쉽게 errors.properties 라는 별도의 파일로 관리한다.
스프링 부트가 해당 메시지 파일을 인식할 수 있게 다음 설정을 추가한다.
( 다음 설정이 없으면 messages만 기본 설정으로 사용 )
spring.messages.basename=messages,errors
참고: errors_en.properties 파일을 생성하면 오류 메시지도 국제화 처리를 할 수 있다.
codes
String 배열로 받기 때문에 new String[]{"message.code"} 와 같이 넣는다.
메시지 코드는 하나가 아니라 배열로 여러 값을 전달할 수 있는데, 순서대로 매칭해서 처음 매칭되는 메시지가 사용된다. 여기서도 없으면 defaultMessage 를 출력한다.
arguments
Object 배열로 받기 때문에 new Object[]{"arg1", "arg2", ... } 와 같이 넣는다.
오류 코드와 메시지 처리2
목표
FieldError , ObjectError 는 다루기 너무 번거롭다. 오류 코드도 좀 더 자동화 할 수 있지 않을까?
컨트롤러에서 BindingResult 는 검증해야 할 객체인 target 바로 다음에 온다. 따라서 BindingResult 는 이미 본인이 검증해야 할 객체인 target 을 알고 있다.
bindingResult.getObjectName(); //@ModelAttribute name
bindingResult.getTarget(); //@ModelAttribute object
rejectValue() , reject()
BindingResult 가 제공하는 rejectValue() , reject() 를 사용하면 FieldError , ObjectError 를 직접 생성하지 않고, 깔끔하게 검증 오류를 다룰 수 있다.
rejectValue()
void rejectValue(@Nullable String field, String errorCode,
@Nullable Object[] errorArgs, @Nullable String defaultMessage);
FieldError 의 대체
- field : 오류 필드명
- errorCode : 오류 코드(메시지에 등록된 코드XX. messageResolver를 위한 오류 코드)
- errorArgs : 오류 메시지에서 {0}, {1}, ... 를 치환하기 위한 값
- defaultMessage : 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지
target object 에 대한 정보는 BindingResult 가 이미 알고 있기 때문에 검증하고자 하는 필드부터 정의해준다.
reject()
void reject(String errorCode, @Nullable Object[] errorArgs, @Nullable String defaultMessage);
ObjectError 의 대체
오류 코드와 메시지 처리3
오류 코드를 만들 때 다음과 같이 자세히 만들 수도 있고,
required.item.itemName : 상품 이름은 필수 입니다.
range.item.price : 상품의 가격 범위 오류 입니다.
또는 다음과 같이 단순하게 만들 수도 있다.
required : 필수 값 입니다.
range : 범위 오류 입니다.
단순하게 만들면 범용성이 좋아서 여러곳에서 사용할 수 있지만, 메시지를 세밀하게 작성하기 어렵다. 반대로 너무 자세하게 만들면 범용성이 떨어진다.
가장 좋은 방법은 범용성으로 사용하다가, 세밀하게 작성해야 하는 경우에는 세밀한 내용이 적용되도록 메시지에 단계를 두는 방법이다.
```properties
#Level1
required.item.itemName: 상품 이름은 필수 입니다.
#Level2
required: 필수 값 입니다.
세밀한 내용이 더 우선순위를 가지도록 개발한다면, 메세지 코드 'required' 를 사용할 때 세밀한 내용이 정의되어 있으면 우선 적용하고, 없다면 범용적인 내용이 적용하도록 할 수 있다.
이렇게 하면 코드 수정 없이 메세지 추가만으로 편리하게 오류 메세지를 관리할 수 있다.
스프링은 MessageCodesResolver 라는 것으로 이러한 기능을 지원한다.
오류 코드와 메시지 처리4
MessageCodesResolver
검증 오류 코드로 메시지 코드들을 생성한다.
MessageCodesResolver 인터페이스이고 DefaultMessageCodesResolver 는 기본 구현체이다.
주로 다음과 함께 사용 ObjectError , FieldError ( rejectValue(), reject() 를 사용하면 내부적으로 알아서 생성되고 바인딩 )
DefaultMessageCodesResolver의 기본 메시지 생성 규칙
객체 오류 ObjectError
객체 오류의 경우 다음 순서로 2가지 생성
1.: code + "." + object name
2.: code
예) 오류 코드: required, object name: item
1.: required.item
2.: required
필드 오류 FieldError
필드 오류의 경우 다음 순서로 4가지 메시지 코드 생성
1.: code + "." + object name + "." + field
2.: code + "." + field
3.: code + "." + field type
4.: code
예) 오류 코드: typeMismatch, object name "user", field "age", field type: int
1. "typeMismatch.user.age"
2. "typeMismatch.age"
3. "typeMismatch.int"
4. "typeMismatch"
동작 방식
rejectValue() , reject() 는 내부에서 MessageCodesResolver 를 사용한다. 여기에서 메시지 코드들을 생성한다.
FieldError, ObjectError 의 생성자를 보면, 오류 코드를 하나가 아니라 여러 오류 코드( String[] )를 가질 수 있다.
MessageCodesResolver 를 통해서 생성된 순서대로 오류 코드를 보관한다.
오류 메시지 출력
타임리프 화면을 렌더링 할 때 th:errors 가 실행된다. 만약 이때 오류가 있다면 생성된 오류 메시지 코드를 순서대로 돌아가면서 메시지를 찾는다. 그리고 없으면 디폴트 메시지를 출력한다.
오류 코드와 메시지 처리5
오류 코드 관리 전략
객체 오류/필드 오류, 범용성에 따라 레벨을 나누어 오류 메세지 설계
핵심은 구체적인 것에서! 덜 구체적인 것으로!
MessageCodesResolver 는 required.item.itemName 처럼 구체적인 것을 먼저 만들어주고, required 처럼 덜 구체적인 것을 가장 나중에 만든다.
이렇게 하면 앞서 말한 것 처럼 메시지와 관련된 공통 전략을 편리하게 도입할 수 있다.
왜 이렇게 복잡하게 사용하는가?
모든 오류 코드에 대해서 메시지를 각각 다 정의하면 개발자 입장에서 관리하기 너무 힘들다. 크게 중요하지 않은 메시지는 범용성 있는 requried 같은 메시지로 끝내고, 정말 중요한 메시지는 꼭 필요할 때 구체적으로 적어서 사용하는 방식이 더 효과적이다.
예)
itemName 의 경우 'required' 검증 오류 메시지가 발생하면 다음 코드 순서대로 메시지가 생성된다.
1. required.item.itemName
2. required.itemName
3. required.java.lang.String
4. required
구체적인 것에서 덜 구체적인 순으로 MessageSource 를 찾는다.
ValidationUtils
ValidationUtils 사용 전
if (!StringUtils.hasText(item.getItemName())) {
bindingResult.rejectValue("itemName", "required", "기본: 상품 이름은 필수입니다.");
}
ValidationUtils 사용 후
Empty , 공백 같은 단순한 기능만 제공
검증 조건(Empty/공백) 까지 포함한 검증 메서드
ValidationUtils.rejectIfEmptyOrWhitespace(bindingResult, "itemName", "required")
정리
1. rejectValue() 호출 ("fieldName", "errorCode")
2. MessageCodesResolver 를 사용해서 검증 오류 코드로 메시지 코드들을 생성 ("errorCode" -> messageCodes[])
3. new FieldError() 를 생성하면서 메시지 코드들을 보관 (codes <- messageCodes[])
4. th:erros 에서 메시지 코드들로 메시지를 순서대로 메시지에서 찾고, 노출
오류 코드와 메시지 처리6
스프링이 직접 만든 오류 메시지 처리
검증 오류 코드
- 개발자가 직접 설정한 오류 코드 -> rejectValue() 를 직접 호출
- 스프링이 직접 검증 오류에 추가한 경우 (주로 타입 바인딩 실패)
스프링은 타입 오류가 발생하면 typeMismatch 라는 오류 코드를 사용한다.
이 오류 코드가 MessageCodesResolver 를 통하면서 4가지 메시지 코드가 생성된다.
--BindResult 로그 결과
Field error in object 'item' on field 'price': rejected value [qqq];
codes [typeMismatch.item.price,typeMismatch.price,typeMismatch.java.lang.Integer,typeMismatch];
...
default message [Failed to convert property value of type 'java.lang.String' to required type 'java.lang.Integer' for property 'price'; nested exception is java.lang.NumberFormatException: For input string: "qqq"]
메세지 코드에 따른 오류 메세지를 따로 추가하지 않았기 때문에 스프링이 생성한 기본 메시지가 출력된다.
#추가 --errors.properties
typeMismatch.java.lang.Integer=숫자를 입력해주세요.
typeMismatch=타입 오류입니다.
타입 바인딩 오류 발생 시 비지니스 검증 로직 전에 입력 폼을 다시 호출하여 타입 바인딩 관련 오류 메세지만 출력하도록 할 수 있다.
정리
메시지 코드 생성 전략은 그냥 만들어진 것이 아니다. Bean Validation을 학습하면 그 진가를 더 확인할 수 있다.
Validator 분리1
목표
현재 컨트롤러가 하는 역할이 너무 많다. (검증 로직 + 성공 로직)
복잡한 검증 로직을 별도의 클래스로 분리하자.
org.springframework.validation.Validator 인터페이스
public interface Validator {
boolean supports(Class<?> clazz);
void validate(Object target, Errors errors);
}
supports() {} : 해당 검증기를 지원하는 여부 확인
return Item.class.isAssignableFrom(clazz) => Item 객체와 Item을 상속받은 자식 클래스까지 true 반환
validate(Object target, Errors errors) : 검증 대상 객체와 BindingResult
싱글톤으로 사용하기 위해 Validator 를 스프링 빈으로 주입 받아서 호출했다.
스프링과 연관하여 장점이 더 있다. -> Validator 분리2
Validator 분리2
스프링이 Validator 인터페이스를 별도로 제공하는 이유는 체계적으로 검증 기능을 도입하기 위해서다. 그런데 앞에서는 검증기를 직접 불러서 사용했고, 이렇게 사용해도 된다. 그런데 Validator 인터페이스를 사용해서 검증기를 만들면 스프링의 추가적인 도움을 받을 수 있다.
WebDataBinder를 통해 Validator사용하기
WebDataBinder 는 스프링의 파라미터 바인딩의 역할을 해주고 검증 기능도 내부에 포함한다.
이를 위해서 검증기 객체를 생성하여 넣어줄 필요가 있다.
검증기 등록
@InitBinder
public void init(WebDataBinder dataBinder) {
dataBinder.addValidators(itemValidator);
}
컨트롤러 호출 때마다 WebDataBinder 객체를 생성하여 검증기를 넣어준다.
이 검증기는 해당 컨트롤러에서 자동으로 실행할 수 있다.
@InitBinder: 해당 컨트롤러에만 영향을 준다. 글로벌 설정은 별도로 필요
검증 대상 앞에 @Validated 를 붙이면 검증기가 실행된다.
동작 방식
@Validated 는 검증기를 실행하라는 애노테이션이다.
이 애노테이션이 붙으면 앞서 WebDataBinder 에 등록한 검증기를 찾아서 실행한다.
그런데 여러 검증기를 등록한다면 그 중에 어떤 검증기가 실행되어야 할지 구분이 필요하다.
이때 검증기들의 supports() 를 호출하여 결과가 true 일 때, validate() 가 호출된다.
글로벌 설정 - 모든 컨트롤러에 다 적용
@SpringBootApplication
public class ItemServiceApplication implements WebMvcConfigurer {
public static void main(String[] args) {
SpringApplication.run(ItemServiceApplication.class, args);
}
@Override
public Validator getValidator() {
return new ItemValidator();
}
}
기존 컨트롤러의 @InitBinder 를 제거해도 글로벌 설정으로 정상 동작한다.
주의: 글로벌 설정을 하면 BeanValidator가 자동 등록되지 않는다.
참고로 글로벌 설정을 직접 사용하는 경우는 드물다.
참고: 검증시 @Validated @Valid 둘다 사용가능하다.
javax.validation.@Valid 를 사용하려면 build.gradle 의존관계 추가가 필요하다.
implementation 'org.springframework.boot:spring-boot-starter-validation'
@Validated 는 스프링 전용 검증 애노테이션이고, @Valid 는 자바 표준 검증 애노테이션이다.
자세한 내용은 다음 Bean Validation에서 설명한다.
