👩💻 검증1 - Validation
📌검증 요구사항
✏️검증 요구사항을 파악해보자
: 지금까지 만든 웹 애플리케이션은 폼 입력시 숫자를 문자로 작성하거나해서 검증 오류가 발생하면 오류 화면으로 바로 이동한다. 웹 서비스는 폼 입력시 오류가 발생하면, 고객이 입력한 데이터를 유지한 상태로 어떤 오류 가 발생했는지 친절하게 알려주어야 한다.
컨트롤러의 중요한 역할중 하나는 HTTP 요청이 정상인지 검증하는 것이다.
📌검증 성공과 실패 로직 차이
✏️검증 (Validation) 기능 학습
:검증 (Validation) 기능을 학습해보자
"상품 저장에 성공했을 시"
서버에서는 검증 로직이 통과하고, 상품을 저장하고, 상품 상세 화면으로 redirect한다.
"상품 저장에 실패했을 시"
고객이 상품 등록 폼에서 상품명을 입력하지 않거나, 가격, 수량 등이 너무 작거나 커서 검증 범위를 넘어서면, 서버 검 증 로직이 실패해야 한다. 이렇게 검증에 실패한 경우 고객에게 다시 상품 등록 폼을 보여주고, 어떤 값을 잘못 입력했는 지 친절하게 알려주어야 한다.
📌BindingResult란?
✏️BindingResult란 무엇일까?
:BindingResult란 스프링이 제공하는 검증 오류 처리 방법이다.
✏️BindingResult 구조
: BindingResult 구조에 대해 알아보자
"BidingResult의 위치는 반드시 @ModelAttribute 뒤에 와야한다."
📌Field 오류와 Object 오류
✏️Field 오류
: Field 오류에 대해 알아보자.
필드에 오류가 있으면 FieldError 객체를 생성하여 BindingResult에 담아둔다.
new Field(ObjectName, field, defaultMessage)
ObejectName = @ModelAttribute 이름
Field = 오류가 발생한 필드 이름
defaultMessage = 오류 기본 메시지
✏️Global 오류
:Global 오류에 대해 알아보자.
특정 필드를 넘어서는 오류가 있다면 ObjectError 객체를 생성한다 (필드가 없는 경우)
ex ) price와 quantity 값이 합쳐서 10000이 넘어야하는데 안넘는 경우 -> 특정 필드가 없음
public objectError(ObjectName, defaultMessage)
bindingResult.addError(new ObjectError("item", "값과 수량의 합이 10,000원 이상이여야 합니다."))
📌Field 오류와 Object 오류
✏️타임리프 스프링 검증 오류 통합 기능
:타임리프 스프링 검증 오류 통합 기능은?
타임리프는 스프링의 `BindingResult` 를 활용해서 편리하게 검증 오류를 표현하는 기능을 제공한다.
✅ #fields : `#fields` 로 BindingResult 가 제공하는 검증 오류에 접근할 수 있다.
ex) {#fields.hasGlobalErrors()}
✅ th:errors : 해당 필드에 오류가 있는 경우에 태그를 출력한다. th:if 의 편의 버전이다.
("th:errors에 담긴 필드가 FieldError에 담겨있으면 ~" 이라는 내용이지 errors내용을 출력한다는게 아니다.)
✅ th:errorclass : `th:field` 에서 지정한 필드에 오류가 있으면 `class` 정보를 추가한다.
서블릿과 비슷한 모양의 컨트롤러 인터페이스를 도입한다.
각 컨트롤러들은 이 인터페이스를 구현하면 된다. 프론트 트롤러는 이 인터페이스를 호출해서 구현과 관계없이 로직의 일관성을
가져갈 수 있다.
📌Field 오류와 Object 오류
✏️타임리프 스프링 검증 오류 통합 기능
:타임리프 스프링 검증 오류 통합 기능은?
타임리프는 스프링의 `BindingResult` 를 활용해서 편리하게 검증 오류를 표현하는 기능을 제공한다.
✅ #fields : `#fields` 로 BindingResult 가 제공하는 검증 오류에 접근할 수 있다.
ex) {#fields.hasGlobalErrors()}
✅ th:errors : 해당 필드에 오류가 있는 경우에 태그를 출력한다. th:if 의 편의 버전이다.
("th:errors에 담긴 필드가 FieldError에 담겨있으면 ~" 이라는 내용이지 errors내용을 출력한다는게 아니다.)
✅ th:errorclass : `th:field` 에서 지정한 필드에 오류가 있으면 `class` 정보를 추가한다.
📌BindingResult에 대해 더 깊게 알아보자
✏️BindingResult
:BindingResult는 정확히 어떤 역할을 수행하는걸까?
BindingResult는 스프링이 제공하는 검증 오류를 보관하는 객체이다. 검증 오류가 발생하면 여기에 보관하면 된다.
BindingResult 가 있으면 `@ModelAttribute` 에 데이터 바인딩 시 오류가 발생해도 컨트롤러가 호출된다
ex) @ModelAttribute에 바인딩 시 타입 오류가 발생하면?
`BindingResult` 가 없으면 ➡️ 400 오류가 발생하면서 컨트롤러가 호출되지 않고, 오류 페이지로 이동한다.
`BindingResult` 가 있으면 ➡️ 오류 정보( `FieldError` )를 `BindingResult` 에 담아서 컨트롤러를 정상 호출한다.
예를들어서 가격에 'qqqq'라는 String 타입을 입력하였을 때, item 객체의 price 변수는 Integer타입이기에, 입력을 제대로 받지 못하고 오류를 출력하게 된다. 이러할 때 BindingResult가 있으면 400 오류등을 출력하는 것이 아닌 컨트롤러를 호출한다.
BindingResult가 없으면 스프링이 컨트롤러를 호출 안하고 튕겨버린다.
(스프링 입장에서 개발자가 오류를 처리하려고 고민이 있나보다 하여 컨트롤러를 호출하면서 오류에 대한 정보를 BindingResult에 담아서 호출해준다.)
☑️ "주의"
1. BindingResult는 검증할 대상 바로 다음에 와야하기 때문에 순서가 중요하다
2. BindingResult는 model에 자동으로 포함되기 때문에 model.addAttribute를 안해주어도 된다.
📌FieldError와 ObejctError
✏️FieldError와 ObjectError에 대해 더 자세하게 알아보자
:FiedlError와 ObjectError는 어떻게 사용하는걸까?
"목표"
: 사용자 입력 오류 메시지가 화면에 남도록 하자.
기존의 코드는 사용자가 잘못 된 입력을 하면 화면에 입력한 값이 사라져버린다. 이 값을 남아있도록 변경해보자.
✏️FieldError 생성자
: FieldError는 다음과 같은 두 가지 생성자를 제공한다.
"파라미터 목록"
(ObjectError도 유사하게 동작한다.)
objectName : 오류가 발생한 객체 이름
field : 오류가 발생한 객체의 필드 이름(오류 필드)
rejectedValue : 사용자가 입력한 값(거절된 값)
bindingFailure : 바인딩 자체가 안된건지, 검증 실패인지 구분 값
(타입 오류로 인한 바인딩 자체가 안된건가?) item객체의 price는 Integer타입인데 입력값으로 Stirng 타입인 'qq'등이 들어옴
(검증 실패인가?) price의 값이 10,000이상 이도록 설정했으나, 입력값으로 10,000보다 작은 4,000등이 들어옴
codes : 메시지 코드
arguments : 메시지에서 사용하는 인자
defaultMessage: 기본 오류 메시지
"스프링의 바인딩 오류 처리"
타입 오류로 바인딩에 실패하면 스프링은 `FieldError` 를 생성하면서 사용자가 입력한 값을 넣어둔다.
그리고 해당 오류를 `BindingResult` 에 담아서 컨트롤러를 호출한다.
따라서 타입 오류 같은 바인딩 실패시에도 사용자의 오류 메시지를 정상 출력할 수 있다.
"정리"
사용자의 입력 데이터가 컨트롤러의 `@ModelAttribute` 에 바인딩되는 시점에 오류가 발생하면 모델 객체에 사용자 입력 값을 유지하기 어렵다. 예를 들어서 가격에 숫자가 아닌 문자가 입력된다면 가격은 "Integer" 타입이므로 문자를 보관할 수 있는 방법이 없다. 그래서 오류가 발생한 경우 사용자 입력 값을 보관하는 별도의 방법이 필요하다. 그리고 이렇게 보관한 사용자 입력 값을 검증 오류 발생시 화면에 다시 출력하면 된다.
FieldError는 오류 발생시 사용자 입력 값을 저장하는 기능을 제공한다.
여기서 "rejectedValue" 가 바로 오류 발생시 사용자 입력 값을 저장하는 필드다."bindingFailure" 는 타입 오류 같은 바인딩이 실패했는지 여부를 적어주면 된다. 여기서는 바인딩이 실패한 것은 아니기 때문에 "false" 를 사용한다.
✏️타임리프의 사용자 값 유지
:th:field= "*{itemName}"
th:field는 굉장히 똑똑하게 작동한다.
정상 상황에서는 모델객체의 값을 사용하지만, 오류가 발생하면 FieldError에서 보관한 값을 사용해서 값을 출력한다.
ex) 정상 상황일때는 itemName을 사용하지만 오류를 발생하면 아까 new FieldError("item", :price", item.getPrice() ... )코드의 사용자가 입력한 값 (item,getPrice()) 값을 사용 함
📌오류 코드와 메시지 처리 1
✏️오류 메시지를 체계적으로 다루는 방법
:오류 메시지를 체계적으로 다루어보자
✏️FieldError 생성자
: FieldError는 다음과 같은 두 가지 생성자를 제공한다.
"파라미터 목록"
(ObjectError도 유사하게 동작한다.)
objectName : 오류가 발생한 객체 이름
field : 오류가 발생한 객체의 필드 이름(오류 필드)
rejectedValue : 사용자가 입력한 값(거절된 값)
bindingFailure : 바인딩 자체가 안된건지, 검증 실패인지 구분 값
(타입 오류로 인한 바인딩 자체가 안된건가?) item객체의 price는 Integer타입인데 입력값으로 Stirng 타입인 'qq'등이 들어옴
(검증 실패인가?) price의 값이 10,000이상 이도록 설정했으나, 입력값으로 10,000보다 작은 4,000등이 들어옴
codes : 메시지 코드
arguments : 메시지에서 사용하는 인자
defaultMessage: 기본 오류 메시지
이처럼 FieldError,ObjectError의 생성자는 "codes" , "arguments" 를 제공한다. 이것은 오류 발생시 오류 코드로 메시지를 찾기 위해 사용된다. codes(message 내용), arguments(메시지로 치환 될 인자)
✏️errors 메시지 파일을 생성하여 관리
:errors 메시지 파일을 생성하여 따로 관리하자
1. errors 메시지 파일 생성
: `messages.properties` 를 사용해도 되지만, 오류 메시지를 구분하기 쉽게 `errors.properties` 라는 별도의 파일로 관리
2. 스프링 부트 메시지 설정 추가
(application.properties)
spring.messages.basename=messages,errors
3. errors.properties 추가
(src/main/resources/errors.properties)
required.item.itemName=상품 이름은 필수입니다.
range.item.price=가격은 {0} ~ {1} 까지 허용합니다.
max.item.quantity=수량은 최대 {0} 까지 허용합니다.
totalPriceMin=가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1}
4. errors에 등록한 메시지를 사용할 수 있도록 컨트롤러 코드 변경
@PostMapping("/add") public String addItemV3(@ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes, Model model) { //FiedlError 검증 (필드 검증) if (!StringUtils.hasText(item.getItemName())) { //item객체의 itemName에 값이 없다면 bindingResult.addError(new FieldError("item", "itemName", item.getItemName(), false, new String[]{"required.item.itemName"}, null, null)); } . . . . //ObjectError 검증 (특정 필드가 아닌 복합 룰 검증) if (item.getPrice() != null && item.getQuantity() != null) { int resultPrice = item.getPrice() * item.getQuantity(); if (resultPrice < 10000) { bindingResult.addError(new ObjectError("item", new String[]{"totalPriceMin"}, new Object[]{10000, resultPrice}, null)); } }
'codes': required.item.itemName` 를 사용해서 메시지 코드를 지정한다.
메시지 코드는 하나가 아니 라 배열로 여러 값을 전달할 수 있는데, 순서대로 매칭해서 처음 매칭되는 메시지가 사용된다.'arguments': Object[]{1000, 1000000} 를 사용해서 코드의 {0} , {1} 로 치환할 값을 전달한다.
📌오류 코드와 메시지 처리 2
✏️오류 코드 자동화
:'FieldError' , 'ObjectError' 는 다루기 너무 번거롭다.
"목표"
FieldError, ObjectError는 다루기가 너무 번거롭다 (파라미터도 너무 많음)
이러한 오류 코드도 좀 더 자동화 할 수 있지 않을까 ?? (ex)item.itemName처럼
컨트롤러에서 "BindingResult" 는 검증해야 할 객체인 "target"바로 다음에 온다.
따라서 "BindingResult"는 이미 본인이 검증해야 할 객체인 "target" 을 알고 있다.
@PostMapping("/add") public String addItem(@ModelAttribute Item item, BindingResult bindingResult, ...){...}bindingResult는 본인이 검증해야 할 객체 item을 이미 알고있음( 항상 검증해야 할 객체 뒤에 오기때문에)
✏️rejectValue(), reject()
:rejectValue()와 reject()에 대해 알아보자.
rejectValue()와 reject()를 사용하면 FieldError, ObjectError를 new로 직접 생성하지 않고, 깔끔하게 검증 오류를 다룰 수 있다.
rejectValue()와 reject()를 사용해서 기존 코드를 단순화해보자!
✏️rejectValue()
:FieldError를 사용해야할 때는 rejectValue()를 사용한다
"rejectValue"의 생성자
void rejectValue(@Nullable String field, String errorCode, @Nullable)Object[] errorArgs, @Nullable String defaultMessage);
field: 오류 필드명
errorCode: 오류 코드
(이 오류 코드는 메시지에 등록된 코드가 아닌, messageResolver를 위한 오류코드이다.)
errorArgs: 오류 메시지에서 {0}을 치환하기 위한 값
defaultMessage: 오류 메시지리를 찾을 수 없을 때 사용하는 기본 메시지
앞서 BindingResult는 어떤 객체를 대상으로 검증하는지 target을 이미 알고 있다고 했다.
따라서 target(item)에 대한 정보는 없어도 된다. 오류 필드명은 동일하게 itemName을 사용했다.
✏️reject()
:ObjectError를 사용해야할 때는 rejectValue()를 사용한다.
void reject(String errorCode, @Nullable Object[] errorArgs, @Nullable String defaultMessage);위의 rejectValue()내용과 같다.
✏️축약된 오류 코드
:오류 코드를 어떻게 축약할 수 있었던 것 일까?
"FieldError()" 를 직접 다룰 때는 오류 코드를 "range.item.price" 와 같이 모두 입력했다.
그런데 "rejectValue()" 를 사용하고 부터는 오류 코드를 "range" 로 간단하게 입력했다. 그래도 오류 메시지를 잘 찾아서 출력한다.
무언가 규칙이 있는 것 처럼 보인다. 이 부분을 이해하려면 "MessageCodesResolver" 를 이해해야 한다.
📌오류 코드와 메시지 처리 3
✏️단순한 오류코드, 자세한 오류코드
오류 코드를 만들 때 아래와 같이 자세히 만들 수도 있고, 단순하게 만들 수도 있다.
"자세한 오류코드"
required.item.itemName : 상품 이름은 필수 입니다.
range.item.price : 상품의 가격 범위 오류 입니다.
"단순한 오류코드"
required : 필수 값 입니다.
range : 범위 오류 입니다.
단순하게 만들면 범용성이 좋아 여러곳에서 사용할 수 있지만, 메시지를 세밀하게 작성하기 어렵고, 너무 자세 하게 만들면 범용성이 떨어진다. 가장 좋은 방법은 범용성으로 사용하다가, 세밀하게 작성해야 하는 경우에는 세밀한 내용이 적용되도록 메시지에 단계를 두는 방법이다.
✏️메시지에 단계를 두는 방법
예를 들어서 `required` 라고 오류 코드를 사용한다고 가정해보자.
다음과 같이 `required` 라는 메시지만 있으면 이 메시지를 선택해서 사용하는 것이다.
required: 필수 값 입니다.
그런데 오류 메시지에 'required.item.itemName' 와 같이 객체명과 필드명을 조합한 세밀한 메시지 코드가 있으면
이 메시지를 높은 우선순위로 사용하는 것이다.
#Level1 required.item.itemName: 상품 이름은 필수 입니다. #Level2 required: 필수 값 입니다.
물론 이렇게 객체명과 필드명을 조합한 메시지가 있는지 우선 확인하고, 없으면 좀 더 범용적인 메시지를 선택하도록 추가 개발을 해야겠지만, 범용성 있게 잘 개발해두면, 메시지의 추가만으로 매우 편리하게 오류 메시지를 관리할 수 있을 것이다.
스프링은 `MessageCodesResolver` 라는 것으로 이러한 기능을 지원한다.
📌오류 코드와 메시지 처리 4
✏️MessageCodesResolver
:MessageCodesResolver를 알아보자
MessageCodesResolver
ㅇ 검증 오류 코드로 메시지 코드들을 생성한다.
ㅇ 'MessageCodesResolver` 인터페이스이고 `DefaultMessageCodesResolver` 는 기본 구현체이다.
ㅇ 주로 다음과 함께 사용 `ObjectError` , `FieldError`
-> 그냥 중요한거는 이러한 MessageCodesResolver같은 기능을 rejectValue()와 reject()는 알아서 해준다.
✏️DefaultMessageCodesResolver의 기본 메시지 생성 규칙
:defaultMessageCodesResolver의 기본 메시지 생성 규칙을 알아보자
"필드 오류(ObjectError)"
필드 오류의 경우 다음 순서로4가지 메시지 코드 생성
1. code + "." + object name + "." + field
2. code + "." + field
3. code + "." + field type
4. code
예시) 오류 code: typeMismatch, object name "user", field "age", field type: int
1. "typeMismatch.user.age"
2. "typeMismatch.age"
3. "typeMismatch.int"
4. "typeMismatch"
"객체 오류(ObjectError)"
객체 오류의 경우 다음 순서로 2가지 생성
1. code + "." + object name
2. code
예시) "오류 code: required" "object name: item"
1. required.item
2. required
✏️(제일 중요)동작 방식
:그래서 동작 방식은 어떻게 되는건가
1. 'rejectValue()' , 'reject()' 는 내부에서 'MessageCodesResolver' 를 사용한다. 여기에서 메시지 코드들을 생성한다.
2. 'FieldError' , 'ObjectError'의 생성자를 보면, 오류 코드를 하나가 아니라 여러 오류 코드를 가질 수 있다.
3. 'MessageCodesResolver' 를 통해서 생성된 순서대로 오류 코드를 보관한다. 'BindingResult' 의 로그를 통해서 확인해보자
-> codes [range.item.price, range.price, range.java.lang.Integer, range]
📌오류 코드와 메시지 처리 5
✏️오류 코드 동작 방식
: 오류 코드의 동작 방식을 코드로 더 확실하게 이해하자
rejectValue()와 reject()를 이용해서
rejectValue("필드명", "메시지", "인자", "기본 메시지")를 넣어주었고, reject("메시지", "인자", 기본 메시지)를 넣어주었다.
errors.properties에 레벨(우선순위)별로 넣어줌
errors.properties의 Level1의 메시지들이 출력 되는 것을 볼 수 있다.
만약 FieldError와 ObjectError의 우선순위 Level1을 모두 주석처리 해준다면 아래처럼 에러가 표시되는 것을 확인할 수 있다.
모두 Level1의 에러 메시지가 아닌 Level3의 에러 메시지가 출력 되는 것을 확인할 수 있다.
✏️ValidationUtils
"ValidationUtils 사용 전"
if (!StringUtils.hasText(item.getItemName())) { bindingResult.rejectValue("itemName", "required", "기본: 상품 이름은 필수입니다."); }
"ValidationUtils 사용 후"ValidationUtils.rejectIfEmptyOrWhitespace(bindingResult, "itemName", "required");
다음과 같이 한줄로 가능, 제공하는 기능은 `Empty` , 공백 같은 단순한 기능만 제공
"정리"
- `rejectValue()` 호출
- `MessageCodesResolver` 를 사용해서 검증 오류 코드로 메시지 코드들을 생성
- `new FieldError()` 를 생성하면서 메시지 코드들을 보관
- `th:erros` 에서 메시지 코드들로 메시지를 순서대로 메시지에서 찾고, 노출
📌오류 코드와 메시지 처리 6
✏️스프링이 직접 만든 오류 메시지 처리
: 검증 오류 코드
검증 오류 코드는 다음과 같이 2가지로 나눌 수 있다.
- 개발자가 직접 설정한 오류 코드 ➡️ "rejectValue()" 를 직접 호출
- 스프링이 직접 검증 오류에 추가한 경우(주로 타입 정보가 맞지 않음)
위의 사진과 같이 `price` 필드에 문자 "qqq"를 입력해보자.
로그를 확인해보면 `BindingResult` 에 `FieldError` 가 담겨있고, 아래와 같은 메시지 코드들이 생성된 것을 확인 할 수 있다.
`codes[typeMismatch.item.price,typeMismatch.price,typeMismatch.java.lang.Integer,ty peMismatch]`
다음과 같이 4가지 메시지 코드가 입력되어 있다.
`typeMismatch.item.price`
`typeMismatch.price`
`typeMismatch.java.lang.Integer`
`typeMismatch`
그렇다. 스프링은 타입 오류가 발생하면 `typeMismatch` 라는 오류 코드를 사용한다.
이 오류 코드가 `MessageCodesResolver` 를 통하면서 4가지 메시지 코드가 생성된 것이다.
-> 사실 그냥 rejectValue()에 "typeMismatch를 넣은것임
그러면 타입 오류가 발생했을때 스프링이 "typeMissmatch"라는 오류 코드를 직접 만들어 주니,
우리가 타입 오류가 발생했을 때 required를 만들어서 errors.properties에 넣었던 것처럼,
`typeMismatch.item.price`
`typeMismatch.price`
`typeMismatch.java.lang.Integer`
`typeMismatch`
이 자동으로 생성된 네 가지 오류 코드를 errors.properties에 넣어서 사용하면 된다.
이후 서버를 실행시키면, 문자 'qqq'를 입력하면 우리가 아래처럼 설정한 에러코드 중, 우선순위가 높은 "숫자를 입력해주세요." 라는 에러가 발생하게 된다.
📌Validator 분리 1
✏️복잡한 검증 로직을 별도로 분리해보자
: 복잡한 검증 로직을 별도로 분리해보자
컨트롤러에서 검증 로직이 차지하는 부분은 매우 크다. 이런 경우 별도의 클래스로 역할을 분리하는 것이 좋다.
✏️"ItemValidator"를 만들어보자
스프링은 검증을 체계적으로 제공하기 위해 다음과 같은 인터페이스를 제공한다.
public interface Validator { boolean supports(Class<?> clazz); void validate(Object target, Errors errors);
"supports() {}" : 해당 검증기를 지원하는 여부 확인(뒤에서 설명)
"validate(Object target, Errors errors)" : 검증 대상 객체와 "BindingResult"
✏️"ItemValidator"를 호출해보자
실행해보면 기존과 완전히 동일하게 동작하는 것을 확인할 수 있다. 검증과 관련된 부분이 깔끔하게 분리되었다.
📌Validator 분리 2
✏️Validator 인터페이스를 별도로 제공하는 이유?
:스프링이 `Validator` 인터페이스를 별도로 제공하는 이유는 체계적으로 검증 기능을 도입하기 위해서다.
앞 에서는 검증기를 직접 불러서 사용했고, 그렇게 사용해도 된다.
그런데 "Validator" 인터페이스를 사용해서 검증기를 만들면 스프링의 추가적인 도움을 받을 수 있다.
✏️WebDataBinder를 통해서 사용하기
:"WebDataBinder" 는 스프링의 파라미터 바인딩의 역할을 해주고 검증 기능도 내부에 포함한다.
ValidationItemControllerV2에 다음과 같은 코드를 추가하자.
이렇게 `WebDataBinder` 에 검증기를 추가하면 해당 컨트롤러에서는 검증기를 자동으로 적용할 수 있다.
`@InitBinder` 해당 컨트롤러에만 영향을 준다. 글로벌 설정은 별도로 해야한다. (마지막에 설명)
✏️Validated 적용
: validator를 직접 호출하는 부분이 사라지고, 대신에 검증 대상 앞에 `@Validated` 가 붙었다.
"동작 방식"
`@Validated` 는 검증기를 실행하라는 애노테이션이다.
이 애노테이션이 붙으면 앞서 "WebDataBinder" 에 등록한 검증기를 찾아서 실행한다.
그런데 여러 검증기를 등록한다 면 그 중에 어떤 검증기가 실행되어야 할지 구분이 필요하다.
이때 "supports()" 가 사용된다. 여기서는 "supports(Item.class)" 호출되고, 결과가 "true" 이므로 "ItemValidator" 의 "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" 를 제거해도 글로벌 설정으로 정상 동작하는것을 확인할 수 있다.
**참고**
1. 참고로 글로벌 설정을 직접 사용하는 경우는 드물다.
2. 검증시 `@Validated` `@Valid` 둘다 사용가능하다.
3. `javax.validation.@Valid` 를 사용하려면 `build.gradle` 의존관계 추가가 필요하다.
4. `implementation 'org.springframework.boot:spring-boot-starter-validation'` `@Validated` 는 스프링 전용 검증
애노테이션이고, `@Valid` 는 자바 표준 검증 애노테이션이다. (자세한 내용은 다음 Bean Validation에서 설명)
'Spring' 카테고리의 다른 글
| 스프링 MVC 2편 - 백엔드 웹 개발 핵심 기술 [Cookie & Session] (0) | 2024.02.20 |
|---|---|
| 스프링 MVC 2편 - 백엔드 웹 개발 핵심 기술 [Bean Validation] (0) | 2024.02.14 |
| 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 4 (0) | 2024.01.20 |
| [Spring] 스프링 MVC 1편, 백엔드 웹 개발 핵심 기술 - 4 (0) | 2024.01.09 |
| [Spring] 스프링 MVC 1편, 백엔드 웹 개발 핵심 기술 - 3 (0) | 2024.01.08 |