검증 처리 / BindingResult 2

이전까지는 각각의 파라미터에 맞는 타입과 데이터들을 넣어 에러를 처리했다.

 

하지만 FieldError와 ObjectError를 모두 신경쓰고 파라미터 하나하나 맞춰주는건 생각보다 귀찮은 일이다.

 

간소화 / rejectValue

 

컨트롤러에서 BindingResult 는 검증해야 할 객체인 target 바로 다음에 온다. 따라서
BindingResult 는 이미 본인이 검증해야 할 객체인 target 을 알고 있다.

 

BindingResult 가 제공하는 rejectValue() , reject() 를 사용하면 FieldError , ObjectError 를 직접 생성하지 않고, 깔끔하게 검증 오류를 다룰 수 있다.

 

rejectValue의 파라미터는 다음과 같다.

void rejectValue(@Nullable String field, String errorCode,
@Nullable Object[] errorArgs, @Nullable String defaultMessage);

• field : 오류 필드명
• errorCode : 오류 코드(이 오류 코드는 메시지에 등록된 코드가 아니다.)
• errorArgs : 오류 메시지에서 {0} 을 치환하기 위한 값
• defaultMessage : 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지

FieldError() 를 직접 다룰 때는 오류 코드를 range.item.price 와 같이 모두 입력했다. 그런데
rejectValue() 를 사용하고 부터는 오류 코드를 range 로 간단하게 입력했다. 

#Level1
required.item.itemName: 상품 이름은 필수 입니다.
#Level2
required: 필수 값 입니다.

만약 이런식으로 메세지가 작성되어 있다면

첫번째 if문의 경우 required로 메세지를 탐색한다.

우리가 명시한 field는 itemName이기 때문에 메세지 중 첫번째가 선택이 될것이다.

이런식으로 메세지를 다양화할 수 있다.

 

 

객체 오류의 순서

1.: code + "." + object name

2.: code

 

필드 오류의 순서

1.: code + "." + object name + "." + field

2.: code + "." + field

3.: code + "." + field type

4.: code

 

에러 단계화

핵심은 구체적인 것에서 덜 구체적인 것으로 가야한다는 것이다.

 

MessageCodesResolver 는 required.item.itemName 처럼 구체적인 것을 먼저 만들어주고,
required 처럼 덜 구체적인 것을 가장 나중에 만든다.
이렇게 하면 메시지와 관련된 공통 전략을 편리하게 도입할 수 있다.