Spring Bean Validation#2 스프링 빈 검증

이 글은 아래글과 이어지는 글이다.

2021.08.29 - [Backend/Spring MVC] - Spring Vaildation#1 검증

Spring Vaildation#1 검증

 

# Bean Validation

WebDataBinder를 사용한다 한들 앞에서 설명한 Validation 객체를 매번 작성하는건 번거롭다. 이를 어노테이션 기반으로 자동으로 되게 만들수는 없을까? → BeanValidation 2.0 (JSR-380)

@Data // @Get, @Set, @toStr, @Equals&Hash, @RequiredArg
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 = 1000000, groups = {SaveCheck.class, UpdateCheck.class})
  private Integer price;

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

  public Item() {
  }

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

Bean Validation은 검증 구현체가 아니라, 어노테이션과 여러 인터페이스들의 모음이다. 마치 JPA - Hinbernate의 관계처럼 동작하며 필요에따라 구현체를 바꿔서 사용할 수 있다. 보통 대부분 Hinbernate Validator 구현체를 많이 사용하는데, 하이버네이트 재단에서 만들어서 붙은 이름이다. JPA랑 기술적인 연관은 없다.

 

다만 표준 인터페이스 (javax.validation.constraints)에서 제공하지 않는 기능을 하이버네이트 Validator가 추가로 제공해주기도 한다. (org.hibernate.validator.constraints)

 

사용하는 검증 애노테이션들은 공식문서만 봐도 알 수 있도록 직관적이다. 한번 읽어보도록 하자.

• 공식 사이트: http://hibernate.org/validator/
• 검증 애노테이션 모음: https://docs.jboss.org/hibernate/validator/6.2/reference
• 공식 메뉴얼: https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/html_single/

Index of /hibernate/validator/6.2/reference

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

 

 

---

# 결국에는 Validtor로 동작한다.

스프링의 기능을 이용해서 어노테이션 기반으로 사용하지만, 내부적으로는 저번 글에서 배웠던 Validtor 인터페이스를 사용한다. 아래 코드를 직접 꺼내 사용할일은 없지만 궁금하다면 아래와 같이 테스트해봐도 된다.

@Test
void beanValidation() {
  // 이 코드를 스프링에서 직접 사용할일은 없으니 걱정말자.
  ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
  Validator validator = factory.getValidator();

  Item item = new Item();
  item.setQuantity(10000);

  Set<ConstraintViolation<Item>> violations = validator.validate(item);
  
  for (ConstraintViolation<Item> violation : violations) {
    System.out.println("violation = " + violation);
    System.out.println("violation = " + violation.getMessage());
  }

}

 

---

# Bean Validation의내부동작

스프링부트 한줄이면 된다. implementation 'org.springframework.boot:spring-boot-starter-validation'

 

이 라이브러리는 LocalValidatorFactoryBean 을 글로벌 Validator 객체로 등록한다. 이 객체가 어노테이션(@NotNull)에  따라 검증을 수행하기 때문에 우리는 아무런 추가작업 없이 검증하려는 곳에 @Valid, @Validated만 붙여주면 된다.

//모든 컨트롤러(글로벌)로 등록되었기 때문에, 이런 코드는 더 이상 필요없다.
//@InitBinder
//public void init(WebDataBinder dataBinder) {
// log.info("init binder {}", dataBinder);
// dataBinder.addValidators(itemValidator);
//}


@PostMapping("/add") // @Validated만 붙이면 적용완료.
public String addItem(@Validated @ModelAttribute Item item, BindingResult bindingResult) {

}

 

우리가 하는건 아무것도 없지만, 내부에서 Bean Validation은 아래와 같이 동작한다.

1. 앱이 시작할 때 BeanVaildaton(구현체 - LocalVaildatorFactoryBean)가 전역으로 컨트롤러에 적용된다.
2. @ModelAttribute 각각 필드에 타입 변환(바인딩)을 시도한다.
   - 만약 타입 바인딩에 실패하면 FieldError('typeMismatch') 를 생성
3. 타입 바인딩에 성공했다면 Validator를 적용. (LocalValidatorFactoryBean가 @어노테이션을 Validator로 변환)
   - 오류코드가 애노테이션 이름으로 적용된다.
4. 해당 오류코드에 해당하는 메시지를 MessageCodeResolver를 이용하여 찾는다. 

타입 변환(바인딩)에 성공한 필드만 Vaildator를 적용한다. 생각해보면 당연한 일

 

우리가 할 일은 errors.properties만 작성해주면 끝이다.

• 오류 메시지를 못찾았다면 @NotBlank(message = "기본값")을 쓰고, 거기도 없다면 라이브러리 기본값을 사용한다.

# errors.properties

# Bean Validation 추가
NotBlank.item.itemNmae = 상품 이름을 적어주세요.

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

 

---

# 객체 (Object) 오류 처리하기

도메인 객체에 애노테이션에 직접 검증 코드를 작성하는 방법도 있으나, 추천하는 방법은 아니다.

@Data // 자바스크립트로 검증.
@ScriptAssert(lang = "javascript", script = "_this.price * _this.quantity >= 
10000")
public class Item {
 //...
}

 

객체 오류 처리 (ObjectError)가 필요하다면 아래와 같이 컨트롤러에 코드로 처리하는게 나은 경우가 많다.

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

    //특정 필드가 아닌 복합 룰 검증
    if (item.getPrice() != null && item.getQuantity() != null) {
      int resultPrice = item.getPrice() * item.getQuantity();
      if (resultPrice < 10000) {
        bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null);
      }
    }

    //검증에 실패하면 다시 입력 폼으로
    if (bindingResult.hasErrors()) {
      log.info("errors={} ", bindingResult);
      return "validation/v3/addForm";
    }

    //성공 로직
    Item savedItem = itemRepository.save(item);
    redirectAttributes.addAttribute("itemId", savedItem.getId());
    redirectAttributes.addAttribute("status", true);
    return "redirect:/validation/v3/items/{itemId}";
}

 

---

# Bean Validation - 각각 다른 검증 적용하기

다음과 같은 요구사항이 있다고 생각해보자.

• 타입 검증
  - 가격, 수량에 문자가 들어가있으면 검증 오류 처리
• 필드 검증
  - 상품명: 필수. 공백 불가능
  - 가격: 최소 1000원, 1백만원 이하
  - 수량: 최대 9999개
• 복합적인 검증 (ObjectError)
  - 최소주문금액: 가격 * 수량의 합은 10000원 이상이어야 거래가 승인됨.

 

하지만 우리 기획자는 등록말고 수정때는 아래와 같은 다른 요구사항을 적용하고 싶다고 한다.

• 등록말고 수정시에는 수량에 제한이 없다.
• 등록은 상관없지만 수정시에는 id값이 필수이다.

그러면 코드를 아래와 같이 수정하면 될까?

@Data // @Get, @Set, @toStr, @Equals&Hash, @RequiredArg
public class Item {

  @NotNull //수정 요구사항 반영 - NotNull 추가
  private Long id;

  @NotBlank
  private String itemName;

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

  @NotNull
  //  @Max(value = 9999) 수정 요구사항 반영- MAX 삭제
  private Integer quantity;

  public Item() {
  }

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

당연히 이러면 등록에서 문제가 생긴다. 그렇다면 등록, 수정에 각각 다른 검증을 적용하고 싶다면 어떻게 해야할까?

 

---

@ 선택지1 - BeanValidation groups

그룹을 지정할 수 있다. 사용할때는 @Vaildated(value = Group.class) 참고로 @Vaild에는 없는 기능이다.

하지만 실무에서는 잘 사용하지 않는 기능이다. 그 이유는 @ 선택지2 를 보자.

package hello.itemservice.domain.item;
public interface SaveCheck {// 저장용 그룹
}

package hello.itemservice.domain.item;
public interface UpdateCheck {// 수정용 그룹
}

@Data // @Get, @Set, @toStr, @Equals&Hash, @RequiredArg
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 = 1000000, groups = {SaveCheck.class, UpdateCheck.class})
  private Integer price;

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

  public Item() {
  }

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

이렇게 정한 그룹은 아래와 같이 사용할 수 있다.

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

 

---

@ 선택지2 - 등록용 폼, 수정용 폼 객체분리

위와 같이 groups로 구분하기에는 코드가 너무 지저분해진다. 또한 실제 서비스에서는 Item 도메인 객체의 정보 말고도 약관 정보, 부가데이터들을 DB에서 추가로 받는데 이것들을 같이 검증할 수 없다.

 

그래서 실무에서는 ItemSaveForm, ItemUpdateForm 처럼 전송 객체를 따로 만든다.

• (기존의 방법) [HTML Form -> Item -> Controller -> Item -> Repository]
  - 장점 : 과정이 간단하다.
  - 단점 : 수정시 검증이 중복될 수 있고, groups로 복잡한 코드가 나온다.
  
  
• (폼 객체 사용) [HTML Form -> ItemSaveForm -> Controller -> Item 생성 -> Repository]
  - 장점 : 데이터가 복잡해도, 별도의 Form 객체를 사용하기에 관리하기 쉽다. 중복을 방지한다.
  - 단점 : 폼 데이터를 기반으로 컨트롤러에서 Item 객체를 생성 & 반환해야한다.

참고로 비슷하다고해서 등록, 수정용 HTML 템플릿을 합쳐서 사용한다면 나중에 유지보수에서 고통받을 수 있다.

 

@Data // Item의 검증은 사용하지 않으므로, 검증 코드를 제거해주자
public class Item {
  private Long id;
  private String itemName;
  private Integer price;
  private Integer quantity;
}

// 참고로 form은 컨트롤러에만 쓰는 객체라 프로젝트경로/web/form/... 에 만든다.
@Data
public class ItemSaveForm {

  @NotBlank
  private String itemName;

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

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

@Data
public class ItemUpdateForm {

  @NotNull
  private Long id;

  @NotBlank
  private String itemName;

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

  //수정에서는 수량은 자유롭게 변경할 수 있다.
  private Integer quantity;
}

 

그리고 컨트롤러에서 아래와 같이 사용하면 된다.

• 단 뷰에서 모델 이름을 item으로 사용하고 싶다면 @ModelAttribute("item")으로 지정해줘야한다.

@Slf4j
@Controller
@RequestMapping("/validation/v4/items")
@RequiredArgsConstructor
public class ValidationItemControllerV4 {

  private final ItemRepository itemRepository;
  
  @GetMapping("/{itemId}") // prg -> post redirect get
  public String item(@PathVariable long itemId, Model model) {
    Item item = itemRepository.findById(itemId);
    model.addAttribute("item", item);
    return "validation/v4/item";
  }
  ...

  @PostMapping("/add") // 등록에는 ItemSaveForm 사용
  public String addItem(@Validated @ModelAttribute("item") ItemSaveForm form,
      BindingResult bindingResult, RedirectAttributes redirectAttributes) {

    //특정 필드가 아닌 복합 룰 검증
    if (form.getPrice() != null && form.getQuantity() != null) {
      int resultPrice = form.getPrice() * form.getQuantity();
      if (resultPrice < 10000) {
        bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null);
      }
    }

    //검증에 실패하면 다시 입력 폼으로
    if (bindingResult.hasErrors()) {
      log.info("errors={} ", bindingResult);
      return "validation/v4/addForm";
    }

    //성공 로직, 폼에서 가져와서 Item을 생성함
    Item item = new Item();
    item.setItemName(form.getItemName());
    item.setPrice(form.getPrice());
    item.setQuantity(form.getQuantity());

    Item savedItem = itemRepository.save(item);
    redirectAttributes.addAttribute("itemId", savedItem.getId());
    redirectAttributes.addAttribute("status", true);
    return "redirect:/validation/v4/items/{itemId}";
  }


  @PostMapping("/{itemId}/edit") // 수정에는 ItemUpdateForm 사용
  public String edit(@PathVariable Long itemId,
      @Validated @ModelAttribute("item") ItemUpdateForm form, BindingResult bindingResult) {

    //특정 필드가 아닌 복합 룰 검증
    if (form.getPrice() != null && form.getQuantity() != null) {
      int resultPrice = form.getPrice() * form.getQuantity();
      if (resultPrice < 10000) {
        bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null);
      }
    }

    if (bindingResult.hasErrors()) {
      log.info("errors={}", bindingResult);
      return "validation/v4/editForm";
    }

    Item itemParam = new Item();
    itemParam.setItemName(form.getItemName());
    itemParam.setPrice(form.getPrice());
    itemParam.setQuantity(form.getQuantity());

    itemRepository.update(itemId, itemParam);
    return "redirect:/validation/v4/items/{itemId}";
  }

}

 

---

# Bean Validation - HTTP 메시지 컨버터 (API @RequestBody)

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

크게 달라지는건 없다. 그냥 @ModelAttribute가 @RequestBody로 바뀌었을 뿐이다.

@Slf4j
@RestController // @ResponseBody가 붙음. 뷰리졸버 대신 Str, Json으로 변환
@RequestMapping("/validation/api/items")
public class ValidationItemApiController {

  @PostMapping("/add")
  public Object addItem(@RequestBody @Validated ItemSaveForm form, BindingResult bindingResult) {
    if (bindingResult.hasErrors()) {
      log.info("검증 오류 발생 errors={}", bindingResult);
      return bindingResult.getAllErrors();
    }

    //...성공 로직 실행...

    return form; // MappingJacksonHttpMessageConverter에 의해 Object -> Json으로 변환됨.
  }
}

 

하지만 여기에는 큰 문제가 있다. Json을 주고받다가 오류가 발생하는 경우, 컨트롤러가 호출되지 않고 예외가 호출된다.즉 아예 form 객체가 만들어지지 않는다 → 검증 불가능!

• @ModelAttribute 에서는 타입이 달라서 변환이 안되도 필드 단위(FieldError)로 처리가 가능했다.
• 하지만 @RequestBody는 각각의 필드단위로 적용할 수 없다. 전체를 객체로 변환해야 한다.

 

즉 우리는 API를 만들 때 아래 3가지 상황에 대한 예외처리와 알맞은 응답을 해주어야 한다. 스프링의 예외처리는 나중에 따로 다룰예정이니, 그때 알아보도록 하자.

• 성공 요청 : 성공 시 로직
• 실패 요청 : Json -> 객체 변환 자체가 실패함 ( form 객체 생성 실패, Vaildator 사용 불가 )
• 검증 오류 요청 : Json -> 객체 변환은 성공했으나 검증은 실패함.