Bean Validation - 검증 어노테이션 사용

Bean Validation

검증기능을 매번 코드로 작성하는 것도 좀 귀찮은 일입니다.

특정 필드에 대한 검증 로직은 대부분 빈 값인지, 특정 크기를 넘는지와 같이 매우 일반적인 로직인데 이런 일반적인 로직을 표준화 한 것이 바로 Bean Validation 입니다.

 

이번 포스팅에서는 Bean Validation 표준 기술을 이용해 어노테이션으로 검증 처리를 해보도록 하겠습니다.

( 엄밀히 말하면 Bean Validation 표준 기술의 구현체인 하이버네이트를 사용할 예정 )

 

설정

Bean Validation 의존관계 추가 - build.gradle - dependencies

implementation 'org.springframework.boot:spring-boot-starter-validation'

하이버네이트에서 지원하는 검증 어노테이션

• @NotBlank, @NotNull, @Max, @Range 등등..
• 아래 링크를 통해 추가적인 어노테이션들을 더 참고하실 수 있습니다.

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

---

Bean Validation 적용

구현했던 검증로직을 사용하지 않고 Bean Validation의 어노테이션을 적용해서 상품관리애플리케이션의 검증처리를 해보도록 하겠습니다.

 

Bean Validation은 우선 도메인에 적용해야 합니다.

@Data
public class Item {

    private Long id;
    
    @NotBlank
    private String itemName;
    @NotNull
    @Range(min=1000,max=1000000)
    private Integer price;

    @NotNull
    @Max(value=9999)
    private Integer quantity;

    public Item() {}

    public Item(String itemName, Integer price, Integer quantity) {
        this.itemName = itemName;
        this.price = price;
        this.quantity = quantity;
    }
}

• @NotBlank : 빈 칸, 공백 허용 X
• @NotNull : null을 허용 X
• @Range(min,max) : min~max 범위 안의 값이어야 함.
• @Max(value) : 최대 value 값 까지만 허용.

 

이렇게 검증로직을 도메인에 걸어주면 스프링은 ValidationFactory로 부터 Validator(검증기)를 자동으로 생성해서 검증 대상을 직접 검증기에 넣고 그 결과를 받습니다. 그 결과는 마찬가지로 BindingResult에 담깁니다.

 

이제 컨트롤러를 수정해보겠습니다.

@PostMapping("/add")
public String addItem(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes)
{

 

마찬가지로 검증 대상인 @ModelAttribute Item item에 @Validated 어노테이션을 붙혀 주어야합니다. ( Validator를 사용하는 원리와 동일합니다. )

 

검증 순서는 이렇게 흘러갑니다.

 

우선 @ModelAttribute 각각의 필드에 타입 변환을 시도합니다.

▶︎ 타입변환 실패시 typeMistmatch로 FieldError 추가

▶︎ 타입 변환 성공 시 하이버네이트 어노테이션 기반 Validator 적용하여 검증 과정을 거쳐 오류 발생시 FieldError 추가

(이 때 에러코드는 어노테이션 기반으로 생성됩니다)

ex) @NotNull의 경우 itemName에서 필드에러 발생 시 NotNull.item.itemName, NotNull.itemName, NotNull.java.lang.String, NotNull 

 

 

Bean Validation은 바인딩에 실패( 타입 변환 실패 )한 필드는 Bean Validation을 적용하지 않습니다.
바인딩에 실패해봐야 Bean Validation을 적용하는게 의미가 없기 떄문에 어쩌면 당연한 얘기.

 

Bean-Validation 검증도 메시지를 별도의 파일을 통해 관리할 수 있습니다.

NotBlank={0} 공백X
Range={0} {2} ~ {1} 허용
Max={0}, 최대 {1}

{0} : 필드명이 주입됩니다.

{1}, {2} .. : 어노테이션 마다 다르기 때문에 위에 올린 링크를 참고해주세요. 

 

메시지는 아래 우선순위대로 기입됩니다.

1. messageSource - 수동 빈, 자동 빈 (메시지 파일) 
2. 어노테이션의 message 속성 ex) @NotBlank(message = "필수 입력사항입니다")
3. 라이브러리가 제공하는 기본 값 사용 

---

Bean Validation - ObjectError 처리

FieldError는 어떻게 처리할지 확실히 알았는데 그렇다면 ObjectError는 Bean-Validation에서 어떻게 처리할까요?

Bean-Validation를 사용해 ObjectError또한 처리할 수 있습니다.

 

바로 @ScriptAssert()를 사용하면 됩니다.

@Data
@ScriptAssert(lang="javascript", script="_this.price * _this.quantity >= 10000", message="수량 * 개수 >= 10000 이어야 합니다.")
public class Item {

 

하지만 실제로 사용해보면 한계가 많습니다. 해당 객체의 범위를 넘어서는 경우에는 해결할 수 없다던지.. 등 이런 경우에는 대응이 어렵습니다. 그래서 권장하는 방법은 아닙니다.

 

ObjectError에 한해서는 그냥 컨트롤러에서 다루는게 가장 유지보수하기 쉽습니다. ObjectError는 컨트롤러에서 로직을 직접 구현해서 bindingresult에 담는 방향을 지향합시다.

---

Bean Validation - 그룹화 (groups)

Bean Validation은 도메인에 직접 검증을 걸어주는 형태라 유연하게 설정할 수 없습니다.

이게 무슨 말이냐면 예를들어 상품관리 시스템에서 등록할 때에는 수량을 최대 10000개로, 수정할 떄에는 수량을 최대 50000개로 설정하고 싶을 때 문제가 발생합니다. 왜냐하면 등록에서도 수정에서도 같은 도메인을 사용하기 때문이에요. 

 

이럴 때 해결할 수 있는 방법이 그룹화입니다.

 

Bean validation의 groups 옵션을 사용해서 등록검증, 수정검증을 그룹으로 나누어 적용할 수 있어요.

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

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

 

@Validated에도 이렇게 그룹을 설정해줘야 합니다.

주의 : @Valid에는 groups 옵션을 적용할 수 없기 때문에 groups을 쓰고자 한다면 @Validated를 사용해야 합니다.

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

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

 

groups은 애플리케이션의 레벨이 높아질수록 복잡하고 읽기 어렵습니다. 실무에서는 groups를 잘 사용하지 않는다고 합니다. 그냥 이런 기능이 있구나 정도로 알아두고 넘어가도록 하겠습니다.

---

전송 객체 분리 후 Bean Validation 적용

지금까지는 등록할 때나 수정할 때나 폼 데이터 전달에 Item 도메인 객체를 사용해서

HTML Form  ➣ Item ➣ Controller ➣ Item ➣ Repository 이런 플로우로 동일하게 흘러갔었습니다.

 

이렇게 Item 도메인으로 퉁쳐서 검증하면 유연하게 검증을 설정할 수 없고, groups라는 귀찮은 옵션을 사용해야 합니다.

 

실무에서는 폼 데이터 전달을 위한 객체를 별도로 지정해서 사용합니다.

• 상품 관리를 예로든다면 등록 폼 객체(ItemSaveForm), 수정 폼 객체(ItemUpdateForm) 이렇게.
• 컨트롤러에서는 폼 객체의 데이터 기반으로 Item 객체를 생성해서 사용하는 추가과정이 있지만 검증이 중복되지 않고, 읽기도 훨씬 쉬워졌어요. 이 방법을 사용하는 걸 권장합니다.
• 등록은 HTML Form ➣ ItemSaveForm ➣ Controller ➣ Item 생성 ➣ Repository
• 수정은 HTML Form ➣ ItemUpdateForm ➣ Controller ➣ Item 생성 ➣ Repository 

폼 데이터 전달을 하면 Item 도메인에는 검증을 걸어줄 필요가 없습니다.
검증은 Form 객체를 통해 별도로 지정.

ItemSaveForm / ItemUpdateForm

컨트롤러에도 적용을 했을 때 등록의 경우

@PostMapping("/add")
public String addItem(@Validated @ModelAttribute("item") ItemSaveForm form, BindingResult bindingResult,
                      RedirectAttributes redirectAttributes)
{

@ModelAttribute로 addForm에서 POST로 넘어온 item을 ItemSaveForm form에 필드 주입합니다. 

1. @Validated로 ItemSaveForm에 검증된 필드만 주입됩니다. 타입 오류 발생 하면 bindingResult에 담기고 Bean-Validation 적용 X
2. @ModelAttribute("item") 으로 설정해주어야 합니다. 이렇게 하지 않으면 Model에 itemSaveForm라는 이름으로 담기기 때문에, 뷰 템플릿에서 접근하는 th:object도 itemSaveForm으로 설정해야 합니다.

if (form.getPrice() != null && form.getQuantity() != null)
{
    int resultPrice = form.getPrice() * form.getQuantity();
    if (resultPrice < 10000) {
        bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null);
    }
}

ObjectError는 Item 도메인의 필드가 아닌 form의 필드를 참고하도록 변경.

Item item = new Item(form.getItemName(),form.getPrice(),form.getQuantity());
Item savedItem = itemRepository.save(item);
redirectAttributes.addAttribute("status",true);
redirectAttributes.addAttribute("itemId",savedItem.getId());

 Repository에는 item이 기록되어야 합니다.  따라서 form 객체의 필드 기반으로 item을 만들고 넣어주었습니다. 

 

수정의 경우도 같은 맥락이기 때문에 따로 과정을 설명하는 건 생략하도록 하겠습니다.

 

---

Bean Validation - @Validated @RequestBody 

@Valid @Validated는 @ModelAttribute 뿐만 아니라 @RequestBody(HttpMessageConverter)에도 적용가능합니다.

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

 

@ModelAttribute에서는 각각의 필드 단위로 세밀하게 적용되기 때문에 특정 필드에 타입이 맞지 않는 오류가 발생해도 나머지 필드는 정상 처리 되어 객체가 생성되고 컨트롤러가 호출합니다.

• 검증 성공의 경우는 당연히 객체 생성 성공 & 컨트롤러 호출
• 타입 오류 발생의 경우 객체 생성에 성공 (오류 발생 필드를 제외한 값들은 주입된 상태로)하고 컨트롤러 또한 호출합니다.
• 필드 오류 발생의 경우에는 객체 생성하고, 컨트롤러 호출했습니다.

 

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

• 검증 성공의 경우는 당연히 객체 생성 성공 & 컨트롤러 호출
• 타입 오류 발생 시에도 MessageConverter에서 객체 생성 실패하기 때문에 컨트롤러 또한 호출하지 못합니다.
• 필드 오류 발생 시에는 타입 오류는 통과한 상태이므로 MessageConverter를 통해 객체는 생성했기 때문에 컨트롤러가 호출되고 @Validator가 적용되어 필드 오류를 잡아냅니다.

Postman을 이용해 테스트

@Slf4j
@RestController
@RequestMapping("/validation/api/items")
public class ValidationItemApiController {

    @PostMapping("/add")
    public Object addItemRequestBody(@Validated @RequestBody ItemSaveForm form,
                          BindingResult bindingResult)
    {
        log.info("API 컨트롤러 호출");
        if(bindingResult.hasErrors())
        {
            log.info("검증 오류 발생 errors={}", bindingResult);
            log.info("{}",form);
            return bindingResult.getAllErrors();
        }

        return form;
    }
    
    @PostMapping("/add2")
    public Object addItemModelAttribute(@Validated @ModelAttirubte ItemSaveForm form,
                          BindingResult bindingResult)
    {
        log.info("API 컨트롤러 호출");
        if(bindingResult.hasErrors())
        {
            log.info("검증 오류 발생 errors={}", bindingResult);
            log.info("{}",form);
            return bindingResult.getAllErrors();
        }

        return form;
    }
}

---

<참고자료>

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

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