[1] Bean Validation - 소개

검증 기능을 매번 코드로 작성하는 것은 번거롭기 때문에 애노테이션을 쓰자.

Bean Validation: 검증 로직을 모든 프로젝트에 적용할 수 있도록 공통화하고 표준화 한 것
구현체가 아니라 Bean Validation 2.0(JSR-380)이라는 기술 표준이다.

즉, 검증 애노테이션과 여러 인터페이스 모음
Bean Validation은 인터페이스만 제공하고 구현체는 바꿔끼울 수 있음.

---

[2] Bean Validation - 시작

jakarta.validation-api: Bean Validation 인터페이스
hibernate-validator: 구현체

📌 검증 애노테이션
@NotBlank: 빈값 + 공백만 있는 경우를 허용 X
@NotNull: null 허용 X
@Range(min = 1000, max = 1000000): 범위 안의 값이어야 함
@Max(9999): 최대 괄호 안 값까지 허용(여기선 9999)

📌
javax.validation .constraints.NotNull
org.hibernate.validator .constraints.Range

javax.validation 로 시작하면 특정 구현에 관계없이 제공되는 표준 인터페이스

org.hibernate.validator 로 시작하면 하이버네이트 validator 구현체를 사용할 때만 제공되는 검증 기능
(실무에서 대부분 하이버네이트 validator를 사용하므로 자유롭게 사용해도 됨)

---

[3] Bean Validation - 프로젝트 준비 V3

📌 단축키
command + R: 원하는 단어로 변경(일괄 변경 가능)
command + shift + R: 디렉토리 단위로 원하는 단어로 변경(일괄 변경 가능)

---

[4] Bean Validation - 스프링 적용

spring-boot-starter-validation 라이브러리를 넣으면 자동으로 Bean Validator를 인지하고 스프링에 통합됨.

스프링 부트는 자동으로 글로벌 Validator로 등록한다.
그래서 Validator가 @NotNull 같은 애노테이션을 보고 검증을 수행한다.
물론, @Valid와 @Validated는 적용해야 한다.

검증 오류가 발생하면 FieldError, ObjectError를 생성해 BindingResult에 담아준다.

1. @ModelAttribute 각각의 필드에 타입 변환 시도
   2-1. 성공했다면 Validator 적용
   2-2. 실패했다면 typeMismatch로 FieldError 추가

바인딩에 성공한 필드만 Bean Validator가 적용된다.
타입 변환에 성공해 바인딩에 성공한 필드여야 Bean Validator 적용이 의미있다.

즉, @ModelAttribute → 각각의 필드 타입 변환 시도 → 변환에 성공한 필드만 BeanValidator 적용

Ex. itemName에 A를 넣었을 땐 타입 변환이 성공하지만 price에 숫자 대신 A를 넣으면 타입 변환에 실패

---

[5] Bean Validation - 에러 코드

📌 @NotBlank
NotBlank.item.itemName
NotBlank.itemName
NotBlank.java.lang.String
NotBlank

📌 @Range
Range.item.price
Range.price
Range.java.lang.Integer
Range

이 순서대로 에러 메시지 코드 생성

BeanValidation 메시지 찾는 순서
1. 생성된 메시지 코드 순서대로 messageSource에서 메시지 찾기
2. 애노테이션 message 속성 사용
3. 라이브러리가 제공하는 기본 값 제공 (공백일 수 없습니다. 같은)

---

[6] Bean Validation - 오브젝트 오류

@ScriptAssert(): BeanValidation에서 특정필드 fieldError가 아닌 해당 오브젝트 관련 오류 objectError 처리
하지만 기능이 너무 약해(해당 객체의 범위를 넘어서는 경우가 잦음) 권장하지 않음.

그냥 오브젝트 오류 관련 부분만 직접 자바 코드로 작성하자.

---

[7] Bean Validation - 수정에 적용

목표: 상품 수정에도 BeanValidation 적용하기

edit()의 Item 객체 모델에 @Validated를 추가하고 editForm으로 이동하는 코드 추가

---

[8] Bean Validation - 한계

현재 수정시 item의 id 값은 항상 들어있도록 로직이 구성되어 있어 검증하지 않아도 된다고 생각했지만 HTTP 요청은 언제든 악의적으로 변경해 요청할 수 있으므로 서버에서 항상 검증해야 한다.

예를 들어 HTTP 요청을 변경해 item의 id 값을 삭제하고 요청할 수 있다. 따라서 최종 검증은 서버에서 진행하는 것이 안전!

요구사항을 조금 수정했는데 수정시에는 수량을 무제한으로, id값은 필수로 두도록 했다. 그 결과 등록이 안된다. 등록시에는 id에 값도 없고 quantity 수량 제한 최대 값인 9999도 적용되지 않았다.

한계: item은 등록과 수정에서 검증 조건의 충돌이 발생하고, 등록과 수정은 같은 BeanValidation을 적용할 수 없다.

---

[9] Bean Validation - groups

등록과 수정을 같이 검증하니까 한계가 있었다. 그래서 다르게 검증하는 방법을 알아보자.

• BeanValidation의 groups기능
• Item을 직접 사용하지 않고, ItemSaveForm, ItemUpdateForm 같은 폼 전송을 위한 별도의 모델 객체를 만들어 사용

BeanValidation groups
: 등록시 검증할 기능과 수정시 검증할 기능을 각 그룹으로 나눠 적용

📌 groups를 사용하기 위해서는 @Valid대신 @Validated를 사용해야 함.

그리고 사실 groups 기능은 실무에서 잘 사용하지 않음. (복잡도가 높음. 실무에서는 등록용 폼 객체와 수정용 폼 객체를 분리해 사용해버림.)

---

[10] Form 전송 객체 분리 - 프로젝트 준비 V4

여태 해왔던 것처럼 파일을 복사하고 버전 일괄적으로 변경해주기

---

[11] Form 전송 객체 분리 - 소개

왜 실무에서 Bean Validation groups를 잘 사용하지 않냐면 등록시 폼에서 전달하는 데이터가 Item 도메인 객체와 딱 맞아떨어지지 않기 때문이다.

실제 실무에서는 회원 등록시 회원 데이터만 전달받는 것이 아니라 약관 등 추가로 받는 사항이 많다.

그래서 Item을 직접 전달받기 보다는, 복잡한 폼의 데이터를 컨트롤러까지 전달할 별도의 객체를 만들어 전달한다.

• ✔️ 폼 데이터 전달에 Item 도메인 객체 사용
  HTML Form → Item → Controller → Item → Repository

장점: Item 도메인 객체를 컨트롤러, 레파지토리까지 직접 전달해 중간 Item을 만드는 과정이 없어 간단
단점: 간단한 경우에만 적용 가능. 수정시 검증이 중복될 수 있고 groups를 사용해야 함.

• ✔️ 폼 데이터 전달을 위한 별도의 객체 사용
  HTML Form → ItemSaveForm → Controller → Item 생성 → Repository

장점: 전송하는 폼데이터가 복잡해도 별도의 폼 객체를 사용해 데이터를 전달 받을 수 있음. 등록/수정 별도의 폼 객체를 만들기 때문에 검증이 중복되지 않음
단점: 폼 데이터를 기반으로 컨트롤러에서 Item 객체를 생성하는 변환 과정이 추가(결국 코드 늘어남)

수정의 경우 등록과 완전히 다른 데이터가 전달된다. 등록시 회원 아이디와 주민 번호를 입력받지만 수정시 이는 수정할 필요가 없다.

그래서 (이 예제의 경우) ItemUpdateForm이라는 별도의 객체로 데이터를 전달 받았다.

---

[12] Form 전송 객체 분리 - 개발

위에서 말했듯 Item 대신 ItemSaveForm을 전달받아 @Validated로 검증을 수행하고 BindingResult로 검증 결과도 받는다.

그리고 참고로 @ModelAttribute("item")에 item 이름을 넣어준 것은 ItemSaveForm의 경우 규칙에 의해 이 이름으로 MVC Model에 담기기 때문에 뷰 템플릿에서 접근하는 th:object이름을 변경하지 않으려고 넣어주었다.

---

[13] Bean Validation - HTTP 메시지 컨버터

HttpMessageConverter에도 @Valid, @Validated를 적용할 수 있다.

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

API의 경우 3가지 경우를 생각해봐야 함
1. 성공 요청: 성공
2. 실패 요청: JSON을 객체로 생성하는 것 자체를 실패
3. 검증 오류 요청: JSON을 객체로 생성하는 것은 성공했으나 검증에서 실패

이는 HttpMessageConverter에서 요청 JSON을 Item 객체로 생성하는 것을 실패한 상황이다. 그래서 컨트롤러 자체가 호출되지 않았다.

객체를 JSON으로 변환해 클라이언트에 전달했고 ObjectError와 FieldError가 반환됐다.

@ModelAttribute vs @RequestBody

HTTP 요청 파라미터를 처리하는 @ModelAttribute는 각각의 필드 단위로 세밀하게 적용된다.
특정 필드에 타입이 맞지 않는 오류가 발생해도 나머지 필드는 정상 처리

HttpMessageConverter는 @ModelAttribute와 다르게 전체 객체 단위로 적용된다.
따라서 메시지 컨버터 작동에 성공하여 Item 객체를 만들어야 @Valid, @Validated가 적용된다.

@ModelAttribute: 필드 단위로 정교하게 바인딩 적용. 특정 필드가 바인딩 되지 않아도 나머지 필드는 정상 바인딩. Validator를 사용한 검증도 적용 가능.

@RequestBody: HttpMessageConverter 단계에서 JSON 데이터를 객체로 변경하지 못하면 이후 단계는 무용지물(진행 X). 컨트롤러 호출 X. Validator 적용 X.

---