[강의] 스프링 MVC 2편 - 백엔드 웹 개발 핵심 기술 4

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 - 인프런 | 강의

4. 검증1 - Validation

※ 검증

• 컨트롤러의 중요한 역할 중 하나는 HTTP 요청이 정상인지 검증하는 것이다.
• 클라이언트 검증은 조작이 가능하여 보안에 취약하며, 서버만으로 검증하면 즉각적인 고객 사용성이 부족해지므로 이 둘을 적절히 섞어서 사용한다. 최종적인 서버 검증은 필수다.

※ 검증 방법들

v1

error를 Map으로 만들고,

if문으로 검증을 한 다음, 생긴 오류를 error Map에 담아서

model.getAttribute("error",error);로 에러 맵을 넣어서 view 파일로 redirect한다.

 

view에서는 아래처럼 에러 여부를 가져온다.

<label for="itemName" th:text="#{label.item.itemName}">상품명</label>
<input type="text" id="itemName" th:field="*{itemName}"
       th:class="${errors?.containsKey('itemName')} ? 'form-control field-error' : 'form-control'"
       class="form-control" placeholder="이름을 입력하세요">
<div class="field-error" th:if="${errors?.containsKey('itemName')}"
     th:text="${errors['itemName']}">
    상품명 오류
</div>

단점 : 타입 오류가 발생하면 컨트롤러에 들어오기도 전에 에러가 발생하기 때문에 타입 에러 처리를 할 수 없다.

           중복이 많다.

           고객이 입력한 

v2

맵을 만들지 않고, 스프링에서 지원하는 BindingResult를 사용하는 방법이다.

파라미터로 BindingResult까지 받아오고

if문으로 에러를 처리하여

bindingResult.addError(new ObjectError("item", "가격 * 수량의 합은 10,000원 이상이어야 합니다. 현재 값 = " + resultPrice)); 꼴로 에러를 처리한다.

+ ObjectError vs FieldError

필드에 오류가 있으면 FieldError(오류 발생시 사용자 입력 값 유지 기능 제공)

특정 필드를 넘어서는 오류가 있으면 ObjectError

BindingResult⊂Errors라서 바꿔 써도 되지만 기능이 적음

 

View에서는 아래처럼 가져다 사용한다.

<label for="itemName" th:text="#{label.item.itemName}">상품명</label>
<input type="text" id="itemName" th:field="*{itemName}"
       th:errorclass="field-error" class="form-control" placeholder="이름을 입력하세요">
<!--th:field로 인해 모든게 다 됨-->
<div class="field-error" th:errors="*{itemName}">
    상품명 오류
</div>

 

BindingResult가 있으면 오류가 생겨도 컨트롤러를 호출해준다 ->없으면 아예 오류페이지로 가버림

 

- 발전 ->

메세지 파일처럼 errors.properties 파일을 만들어 따로 관리하는 방법이 있다. 국제화도 가능하다.

 

- 발전 ->

FieldError나 ObjectError를 생성하지 않고

bindingResult.rejectValue("price", "range", new Object[]{1000, 1000000}, null);

이렇게만 작성할 수도 있다.

에러 코드는 errors.properties 에서 필드명과 조합해서 찾아준다.

(ex)range.item.price, range.price, range.java.lang.Integer, range)

여러 개 있는 경우, 구체적인 순부터 우선순위로 사용한다. (오류 메세지 재사용 가능)

MessageCodesResolver가 이런 기능을 지원한다.

 

※ Validatior 분리

Validator를 implement해서 CustomValidator를 만든다.

CustomValidator 안에는 bindingResult를 파라미터로 받아,

if문으로 에러를 체크하고 에러를 bindingResult에 저장한다.

customValidator.validate(target, bindingResult); 한 줄로 validation을 할 수 있다.

-발전->

@InitBinder
public void init(WebDataBinder dataBinder) {
    log.info("init binder {}", dataBinder);
    dataBinder.addValidators(itemValidator);
}

에 validator들을 등록해두면,

파라미터의 검증할 객체 앞에@Validated를 붙임으로써 검증을 적용할 수 있다.

 

5. 검증2 - Bean Validation

 

※ Bean Validation

검증 코드를 애노테이션 하나로 끝내자

 

검증 애노테이션 모음:

https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/html_single/#validator-defineconstraints-spec

Hibernate Validator 6.2.5.Final - Jakarta Bean Validation Reference Implementation: Reference Guide

@Data
public class Item {

    private Long id;

    @NotBlank
    private String itemName;

    @NotNull
    @Range(min = 1000, max = 10000)
    private Integer price;

    @NotNull
    @Max(9999)
    private Integer quantity;
}

검증 순서
1. @ModelAttribute 각각의 필드에 타입 변환 시도
    1. 성공하면 다음으로
    2. 실패하면 typeMismatch 로 FieldError 추가
2. Validator 적용

-> 바인딩에 성공한 필드만 Bean Validation 적용

바인딩에 성공하지 못하면 일단 TypeMismatch가 먼저 뜬다

 

주의 : 글로벌 Validator를 직접 등록하면 Bean Validator가 글로벌 Validator로 등록되지 않는다.

 

※ ObjectError

@ScriptAssert(lang = "javascript", script = "_this.price * _this.quantity >=
10000") 방식을 사용하면 처리할 수 있는데, 억지인 부분이 좀 있다. -> 이 부분만 자바 코드로 처리하는 게 차라리 나음

 

※ Groups

@Validated 는 스프링 전용 검증 애노테이션이고, @Valid 는 자바 표준 검증 애노테이션이다

Validated는 groups가 가능해서, Validation class들을 등록시켜 놓고, 필요한 것만 사용할 수 있다.

@Data
public class Item {

    @NotNull(groups = UpdateCheck.class)
    private Long id;

    @NotBlank(groups = {SaveCheck.class, UpdateCheck.class})
    private String itemName;

    @NotNull(groups = {SaveCheck.class, UpdateCheck.class})
    @Range(min = 1000, max = 10000)
    private Integer price;

    @NotNull(groups = {SaveCheck.class, UpdateCheck.class})
    @Max(9999)
    private Integer quantity;
}

@PostMapping("/add")
public String addItemV5(@Validated(SaveCheck.class) @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes, Model model) {


@PostMapping("/{itemId}/edit")
public String edit(@PathVariable Long itemId, @Validated(UpdateCheck.class) @ModelAttribute Item item, BindingResult bindingResult) {

※ Form 전송 객체 분리 

실무에서는 사실 등록, 수정의 경우 받는 데이터가 아예 다르다.

따라서 groups를 사용하는 것보다 아예 별도의 객체를 사용하는 것이 낫다.

 

 

※ @ModelAttribute vs @RequestBody

(@ModelAttribute 는 HTTP 요청 파라미터(URL 쿼리 스트링, POST Form)를 다룰 때 사용한다.
@RequestBody 는 HTTP Body의 데이터를 객체로 변환할 때 사용한다. 주로 API JSON 요청을 다룰 때
사용한다.)

RequestBody에도 Valid, Validated를 적용할 수 있음.

하지만, @ModelAttribute 각각의 필드 단위로 세밀하게 적용됨 -> 특정 필드가 바인딩 되지 않아도 나머지 필드 사용 가능

반면 @RequestBody는 HttpMessageConverter 단계에서 JSON 데이터를 객체로 변경하지 못하면 이후
단계 자체가 진행되지 않고 예외가 발생한다. 컨트롤러도 호출되지 않고, Validator도 적용할 수 없다.