-
[김영한 스프링] 24. 검증1 Validation - 오류 코드와 메시지 처리4, 5, 6Spring/스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 2023. 9. 1. 23:18
오류 코드와 메시지 처리4
MessageCodesResolverTest
test/java/hello/itemservice/validation/MessageCodesResolverTest 생성
messageCodesResolverObject
실행
messageCodesResolverField
bindingResult.rejectvalue가 내부에서 codeResolver를 호출함
실행
package hello.itemservice.validation; import org.assertj.core.api.Assertions; import org.junit.jupiter.api.Test; import org.springframework.validation.DefaultMessageCodesResolver; import org.springframework.validation.MessageCodesResolver; import static org.assertj.core.api.Assertions.*; public class MessageCodesResolverTest { MessageCodesResolver codesResolver = new DefaultMessageCodesResolver(); @Test void messageCodesResolverObject() { String[] messageCodes = codesResolver.resolveMessageCodes("required", "item"); assertThat(messageCodes).containsExactly("required.item", "required"); } @Test void messageCodesResolverField() { String[] messageCodes = codesResolver.resolveMessageCodes("required", "item", "itemName", String.class); assertThat(messageCodes).containsExactly("required.item.itemName", "required.itemName", "required.java.lang.String", "required"); } }
MessageCodesResolver
- 검증 오류 코드로 메시지 코드들을 생성한다.
- MessageCodesResolver 인터페이스이고 DefaultMessageCodesResolver는 기본 구현체이다.
- 주로 다음과 함께 사용 ObjectError, FieldError
DefaultMessageCodesResolver의 기본 메시지 생성 규칙
객체 오류
객체 오류의 경우 다음 순서로 2가지 생성
1.: code + "." + object name
2.: code
예) 오류 코드: required, object name: item
1.: required.item
2.: required필드 오류
필드 오류의 경우 다음 순서로 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의 생성자를 보면, 오류 코드를 하나가 아니라 여러 오류 코드를 가질 수 있다.
- MessageCodesResolver를 통해서 생성된 순서대로 오류 코드를 보관한다.
- 이 부분을 BindingResult의 로그를 통해서 확인해보자.
- codes [range.item.price, range.price, range.java.lang.Integer, range]
FieldError rejectValue("itemName", "required")
다음 4가지 오류 코드를 자동으로 생성
- required.item.itemName
- required.itemName
- required.java.lang.String
- required
ObjectError reject("totalPriceMin")
다음 2가지 오류 코드를 자동으로 생성
- totalPriceMin.item
- totalPriceMin
오류 메시지 출력
타임리프 화면을 렌더링 할 때 th:errors가 실행된다. 만약 이때 오류가 있다면 생성된 오류 메시지 코드를 순서대로 돌아가면서 메시지를 찾는다. 그리고 없으면 디폴트 메시지를 출력한다.
오류 코드와 메시지 처리5
오류 코드 관리 전략
핵심은 구체적인 것에서! 덜 구체적인 것으로!
MessageCodesResolver는 required.item.itemName처럼 구체적인 것을 먼저 만들어주고, required처럼 덜 구체적인 것을 가장 나중에 만든다.
이렇게 하면 앞서 말한 것처럼 메시지와 관련된 공통 전략을 편리하게 도입할 수 있다.
왜 이렇게 복잡하게 사용하는가?
모든 오류 코드에 대해서 메시지를 각각 다 정의하면 개발자 입장에서 관리하기 너무 힘들다.
크게 중요하지 않은 메시지는 범용성 있는 requried같은 메시지로 끝내고, 정말 중요한 메시지는 꼭 필요할 때 구체적으로 적어서 사용하는 방식이 더 효과적이다.
errors.properties
#required.item.itemName=상품 이름은 필수입니다. #range.item.price=가격은 {0} ~ {1} 까지 허용합니다. #max.item.quantity=수량은 최대 {0} 까지 허용합니다. #totalPriceMin=가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1} #==ObjectError== #Level1 totalPriceMin.item=상품의 가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1} #Level2 - 생략 totalPriceMin=전체 가격은 {0}원 이상이어야 합니다. 현재 값 = {1} #==FieldError== #Level1 required.item.itemName=상품 이름은 필수입니다. range.item.price=가격은 {0} ~ {1} 까지 허용합니다. max.item.quantity=수량은 최대 {0} 까지 허용합니다. #Level2 - 생략 #Level3 required.java.lang.String = 필수 문자입니다. required.java.lang.Integer = 필수 숫자입니다. min.java.lang.String = {0} 이상의 문자를 입력해주세요. min.java.lang.Integer = {0} 이상의 숫자를 입력해주세요. range.java.lang.String = {0} ~ {1} 까지의 문자를 입력해주세요. range.java.lang.Integer = {0} ~ {1} 까지의 숫자를 입력해주세요. max.java.lang.String = {0} 까지의 문자를 허용합니다. max.java.lang.Integer = {0} 까지의 숫자를 허용합니다. #Level4 required = 필수 값 입니다. min= {0} 이상이어야 합니다. range= {0} ~ {1} 범위를 허용합니다. max= {0} 까지 허용합니다.
크게 객체 오류와 필드 오류를 나누었다. 그리고 범용성에 따라 레벨을 나누어두었다.
itemName의 경우 required 검증 오류 메시지가 발생하면 다음 코드 순서대로 메시지가 생성된다.
- required.item.itemName
- required.itemName
- required.java.lang.String
- required
그리고 이렇게 생성된 메시지 코드를 기반으로 순서대로 MessageSource에서 메시지에서 찾는다.
구체적인 것에서 덜 구체적인 순서대로 찾는다. 메시지에 1번이 없으면 2번을 찾고, 2번이 없으면 3번을 찾는다.
이렇게 되면 만약에 크게 중요하지 않은 오류 메시지는 기존에 정의된 것을 그냥 재활용하면 된다!
실행
Level1 매칭
Level2
Level1 주석 처리
실행
Level3 매칭
Level4
Level3 주석 처리
실행
Level4 매칭
ValidationUtils
ValidationUtils 사용 전
if (!StringUtils.hasText(item.getItemName())) { bindingResult.rejectValue("itemName", "required"); }
ValidationUtils 사용 후
다음과 같이 한줄로 가능, 제공하는 기능은 Empty, 공백 같은 단순한 기능만 제공
ValidationUtils.rejectIfEmptyOrWhitespace(bindingResult, "itemName", "required");
176 ~ 178라인 코드를 한줄로 가능
하지만 Empty, 공백 같은 단순한 기능만 제공
정리
- rejectValue() 호출
- MessageCodesResolver를 사용해서 검증 오류 코드로 메시지 코드들을 생성
- new FieldError()를 생성하면서 메시지 코드들을 보관
- th:erros에서 메시지 코드들로 메시지를 순서대로 메시지에서 찾고, 노출
오류 코드와 메시지 처리6
스프링이 직접 만든 오류 메시지 처리
검증 오류 코드는 다음과 같이 2가지로 나눌 수 있다.
- 개발자가 직접 설정한 오류 코드 -> rejectValue()를 직접 호출
- 스프링이 직접 검증 오류에 추가한 경우(주로 타입 정보가 맞지 않음)
실행
가격에 타입이 맞지 않는 문자 입력
결과
스프링이 직접 typeMismatch라고 넣어줌
다음과 같이 4가지 메시지 코드가 입력되어 있다.
- typeMismatch.item.price
- typeMismatch.price
- typeMismatch.java.lang.Integer
- typeMismatch
스프링은 타입 오류가 발생하면 typeMismatch라는 오류 코드를 사용한다. 이 오류 코드가 MessageCodesResolver를 통하면서 4가지 메시지 코드가 생성된 것이다.
error.properties
#추가 typeMismatch.java.lang.Integer=숫자를 입력해 주세요. typeMismatch=타입 오류입니다.
실행
정리
결과적으로 소스코드를 하나도 건들지 않고, 원하는 메시지를 단계별로 설정할 수 있다.
메시지 코드 생성 전략은 그냥 만들어진 것이 아니다. 조금 뒤에서 Bean Validation을 학습하면 그 진가를 더 확인할 수 있다.
출처 : https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2
'Spring > 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술' 카테고리의 다른 글
[김영한 스프링] 26. 검증2 Bean Validation - 소개 & 시작 & 프로젝트 준비 V3 (1) 2023.09.05 [김영한 스프링] 25. 검증1 Validation - Validator 분리1, 2 (0) 2023.09.02 [김영한 스프링] 23. 검증1 Validation - 오류 코드와 메시지 처리1, 2, 3 (0) 2023.09.01 [김영한 스프링] 22. 검증1 Validation - FieldError, ObjectError (0) 2023.08.30 [김영한 스프링] 21. 검증1 Validation - BindingResult (0) 2023.08.30