MVC / Validation

검증 요구사항

타입 검증

>> 가격, 수량에 문자가 들어가면 검증 오류 처리

 

필드 검증

>> 상품명 : 필수, 공백 x

>> 가격 : 1000원 이상, 1백만원 이하

>> 수량 : 최대 9999

 

특정 필드의 범위를 넘어서는 검증

>> 가격 * 수량의 합은 10,000원 이상

 

컨트롤러의 중요한 역할 중 하나

>> HTTP 요청이 정상인지 검증

 

검증 직접 처리

 

BindingResult

필드에 오류가 있으면 FieldError 객체 생성해서 bindingResult에 담음

>> objectName : @ModelAttribute 이름, field : 오류 발생 필드 이름, defaultMessage : 오류 기본 메시지

 

필드를 넘어서는 오류가 있으면 ObjectError 객체를 생성해서 bindingResult에 담음

>> objectName : @ModelAttribute 이름, defaultMessage : 오류 기본 메시지

 

타임리프 스프링 검증 오류 통합 기능

스프링의 BindingResult를 활용해 편리하게 검증 오류 표현 기능 제공

>> #fields : BindingResult가 제공하는 검증 오류에 접근 가능

>> th:errors : 해당 필드에 오류가 있는 경우 태그 출력, th:if의 편의 버전

>> th:errorclass : th:field에서 지정한 필드에 오류 있으면 class 정보 추가

 

BindingResult는 스프링이 제공하는 검증 오류를 보관하는 객체

>> @ModelAttribute에 데이터 바인딩 시 오류가 발생해도 컨트롤러 호출됨!

>> 오류 정보(FieldError)를 BindingResult에 담아 컨트롤러 정상 호출

 

BindingResult에 검증 오류를 적용하는 3가지 방법

>> @ModelAttribute의 객체에 타입 오류 등으로 바인딩이 실패하는 경우 스프링이 FieldError 생성해서 BindingResult에 넣어줌

>> 개발자가 직접 넣어줌

>> Validator 사용

 

FieldError, ObjectError

사용자 입력 오류 메시지가 화면에 남도록

 

FieldError 생성자

두 가지 생성자 제공

 

objectName : 오류가 발생한 객체 이름

field : 오류 필드

rejectedValue : 사용자가 입력한 값(거절된 값)

bindingFailure : 타입 오류 같은 바인딩 실패인지, 검증 실패인지 구분 값

codes : 메시지 코드

arguments : 메시지에서 사용하는 인자

defaultMessage : 기본 오류 메시지

 

ObjectError도 유사

 

오류 발생시 사용자 입력 값 유지

FieldError는 오류 발생시 사용자 입력 값을 저장

>> rejectedValue : 오류 발생시 사용자 입력 값 저장 필드

 

오류 코드와 메시지 처리 1 

errors.properties 메시지 파일

 

codes : required.item.itemName을 사용해 메시지 코드 지정

>> 메시지 코드는 하나가 아니라 배열로 여러 값 전달 가능, 순서대로 매칭해 처음 매칭되는 메시지 사용

arguments : Object[]{1000, 1000000}을 사용해 코드의 {0}, {1}로 치환할 값 전달

 

오류 코드와 메시지 처리 2

컨트롤러에서 BindingResult는 검증해야할 객체인 target 바로 다음에 옴

>> BindingResult는 이미 본인이 검증해야 할 객체인 target을 알고 있음

 

rejectValue()

field : 오류 필드명

errorCode : 오류 코드(메시지에 등록된 코드 x, messageResolver를 위한 오류 코드)

errorArgs : 오류 메시지에서 {0}을 치환하기 위한 값

defaultMessage : 오류 메시지를 찾을 수 없을 떄 사용하는 기본 메시지

 

오류 코드와 메시지 처리 3

단순하게 만들면 범용성이 좋지만 메시지를 세밀히 작성하기 어려움

반대로 자세하게 만들면 범용성이 떨어짐

>> 가장 좋은 방법은 범용성으로 사용하다가 세밀하게 작성해야 하는 경우에 세밀한 내용이 적용되게 단계를 두는 것

 

MessageCodesResolver

검증 오류 코드로 메시지 코드들 생성

MessageCodesResolver 인터페이스고 DefaultMessageCodesResolver가 기본 구현체

>> 주로 ObjectError, FieldError와 함께 사용

 

DefaultMessageCodesResolver의 기본 메시지 생성 규칙

객체 오류

1. code + "." + object name

2. code

 

예) 오류 코드: required, object name: item

1. required.item

2. required

 

필드 오류

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 사용

>> 메시지 코드들 생성

MessageCodesResolver를 통해 생성된 순서대로 여러 오류 코드들 보관

 

오류 메시지 출력

타임리프 화면을 렌더링 할 때 th:errors 실행

>> 생성된 오류 메시지 코드를 순서대로 돌아가면서 찾고 없으면 디폴트 메시지 출력

 

오류 코드와 메시지 처리 4

스프링이 직접 만든 오류 메시지 처리

스프링은 타입 오류가 발생하면 typeMismatch라는 오류 코드 사용

 

Validator 분리

컨트롤러에서 검증 로직을 별도의 클래스로 역할을 분리

supports() {} : 해당 검증기를 지원하는 여부 확인

validate() : 검증 대상 객체와 BindingResult

 

WebDataBinder 사용

해당 컨트롤러에서는 검증기를 자동으로 적용 가능

>> @InitBinder : 해당 컨트롤러에만 영향, 글로벌 설정 별도 필요

 

@Validated 적용

검증 대상 앞에 붙으며 검증기를 실행하라는 애노테이션

WebDataBinder에 등록한 검증기 찾아서 실행

>> 여러 검증기를 등록하면 어떤 검증기를 고를지 구분이 필요

>> 이때 supports() 사용

 

 

 

 

 

 

 

 

출처 : 김영한, 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술