[1] 검증 요구사항

➕ 추가된 요구사항

타입 검증: 가격, 수량에 문자가 들어가면 검증 오류 처리
필드 검증: 상품명 필수, 가격 범위 설정, 수량 한계
특정 필드의 범위를 넘어서는 검증: 가격 * 수량의 합은 10,000원 이상

컨트롤러의 중요한 역할 중 하나는 HTTP 요청이 정상인지 검증하는 것

📌
- 클라이언트 검증은 조작할 수 있으므로 보안에 취약(포스트맨을 생각해봐라)
- 서버만으로 검증하면, 즉각적인 고객 사용성 부족
- 둘을 적절히 섞어 사용하되, 최종적으로 서버 검증은 필수
- API 방식을 사용하면 API 스펙을 잘 정의해 검증 오류를 API 응답 결과에 잘 남겨주어야 함

---

[2] 프로젝트 설정 V1

validation 프로젝트

---

[3] 검증 직접 처리 - 소개

---

[4] 검증 직접 처리 - 개발

Map<String, String> errors = new HashMap<>();: 검증 오류 발생시 어떤 검증에서 오류가 발생했는지 정보를 담아둠.
어떤 필드에서 오류가 발생했는지 구분하기 위해 오류가 발생한 필드명을 key로 사용함.
이후 뷰에서 이 데이터를 사용해 고객에게 친절한 오류 메시지를 출력할 수 있음.

th:if: 조건에 만족할 때만 해당 HTML 태그를 출력할 수 있음.

📌
errors가 null이라면 등록폼에 진입한 시점에는 errors가 없다.
따라서 errors.containskey()를 호출하는 순간 NullPointerException이 발생한다.

errors?.: errors가 null일 때 NullPointerException이 발생하는 대신, null을 반환하는 문법
th:if에서 null은 실패로 처리되므로 오류 메시지가 출력되지 않음.

th=classappend: 해당 필드에 오류가 있으면 field-error라는 클래스 정보를 더해 폼의 색을 빨간색으로 강조. 값이 없다면 _(No-Operation)을 사용해 아무것도 하지 않음.

v1의 문제점

• 뷰 템플릿에서 중복 처리가 많다.
• 타입 오류 처리가 안된다.
• 타입 오류가 발생했을 때 고객이 어떤 내용 때문에 오류가 발생했는지 이해할 수 없다.
• 결국 고객이 입력한 값도 어딘가 별도로 관리가 되어야 한다.

---

[5] 프로젝트 준비 V2

📌 mac 기준 command+R을 이용해서 복사한 v1 파일 이름을 v2로 한 번에 바꿀 수 있음

폴더의 모든 v1을 v2로 바꾸기 위해서는 해당 폴더에 command+shift+R

---

[6] BindingResult1

⭐️핵심 BindingResult

📌 @ModelAttribute와 BindingResult 파라미터 순서를 주의하자.
(BindingResult는 검증할 대상 바로 다음에 와야 한다.)
(BindingResult는 Model에 자동 포함)

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

• @fields: 이걸로 BindingResult가 제공하는 검증 오류에 접근
• th:errors: 해당 필드에 오류가 있는 경우 태그를 출력. th:if의 편의 버전
• th:errorclass: th:field에서 지정한 필드에 오류가 있으면 class 정보를 추가

---

[7] BindingResult2

BindingResult가 있으면 @ModelAttribute에 데이터 바인딩 시 오류가 발생해도 컨트롤러가 호출된다.

• BindingResult가 없다면 400 오류가 발생하며 컨트롤러 호출 ❌, 오류페이지로 이동 (즉, 사용자가 보기엔 어떤 오류가 발생했는지 알 수 없음)
• BindingResult가 있다면 오류 정보(FieldError)를 BindingResult에 담아 컨트롤러를 정상 호출

📌 BindingResult에 검증 오류를 적용하는 세 가지 방법
1. @ModelAttribute의 객체에 타입 오류 등으로 바인딩이 실패하는 경우 스프링이 FieldError를 생성해서 BindingResult에 넣어준다.

2. 개발자가 직접 넣어준다.

3. Validator 사용

BindingResult는 인터페이스이며 Errors 인터페이스를 상속받고 있다.
실제로 넘어오는 구현체는 BeanPropertyBindingResult라는 것인데 두 인터페이스를 구현하고 있으므로 BindingResult와 Errors 둘 중에 하나를 사용하면 된다.
Errors 인터페이스는 단순한 오류 저장과 조회 기능을 제공하지만 BindingResult는 여기에 기능을 추가적으로 제공한다.
addError()도 BindingResult가 제공하므로 여기서는 BindingResult를 사용하며 관례상으로도 BindingResult를 많이 사용한다.

아직 고객이 조건에 맞지 않게 입력해 제출하면 고객이 입력했던 내용들이 사라진다.

---

[8] FieldError, ObjectError

📌 FieldError 생성자

📌 FieldError 파라미터 목록

• objectName: 오류가 발생한 객체 이름
• field: 오류 필드
• rejectedValue: 사용자가 입력한 값 (거절된 값)
• bindingFailure: 타입 오류 같은 바인딩 실패인지, 검증 실패인지 구분 값
• codes: 메시지 코드
• arguments: 메시지에서 사용하는 인자
• defaultMessage: 기본 오류 메시지

사용자의 입력 데이터가 컨트롤러의 @ModelAttribute에 바인딩되는 시점에 오류가 발생하면 모델 객체에 사용자 입력 값을 유지하기 어렵다.
➡️ FieldError는 오류 발생시 사용자 입력 값을 저장하는 기능을 제공한다.

여기서 rejectedValue가 바로 오류 발생시 사용자 입력 값을 저장하는 필드이다. bindingFailure에는 타입 오류 같은 바인딩이 실패했는지에 대한 여부를 적어준다.

타임리프의 사용자 입력 값 유지
th:field에서 오류가 발생하면 FieldError에서 보관한 값을 사용해 값을 출력한다.

스프링의 바인딩 오류 처리
타입 오류로 바인딩에 실패하면 스프링은 FieldError를 생성하며 사용자가 입력한 값을 넣어둔다. 그리고 해당 오류를 BindingResult에 담아 컨트롤러를 호출한다.
그래서 타입 오류와 같은 바인딩 실패에도 사용자의 오류 메시지를 정상 출력할 수 있는 것이다.

---

[9] 오류 코드와 메시지 처리1

목표: 오류 메시지도 "상품 상세", "상품 수정"...처럼 일관적으로 관리하자.
➡️ 강의 예제처럼 한글로 하고 싶었으나 한글 인코딩이 안돼서 영어로 갈김 ㅠㅠ

바로 위에서 알아본 FieldError를 사용할 것

code: (예제에서는) required.item.itemName를 사용해 메시지 코드를 지정. 메시지 코드는 하나가 아니라 배열로 여러 값을 전달 할 수 있어, 순서대로 매칭해 처음 매칭되는 메시지가 사용됨.
arguments: Object[]{1000, 1000000}를 사용해 코드의 {0}, {1}로 치환할 값을 전달.

---

[10] 오류 코드와 메시지 처리2

목표: FieldError, ObjectError는 다루기 번거로우므로 더 자동화시키자.

예전에 BindingResult는 파라미터에서 순서가 중요하다고 했었다. BindingResult는 검증해야 할 객체 target바로 다음에 온다.
따라서 BindingResult는 이미 본인이 검증해야 할 객체인 target을 알고 있다.

BindingResult가 제공하는 rejectValue(), reject()를 사용하면 FieldError, ObjectError를 직접 생성하지 않고도 깔끔하게 검증 오류를 다룰 수 있다.

📌 rejectValue()

• field: 오류 필드명
• errorCode: 오류 코드(메시지에 등록된 코드 X, messageResolver를 위한 오류 코드 O)
  단지 지금은 "에러 코드 하나만 넣으면 오브젝트, 필드를 참고해 코드를 만들어주나보다"라고만 이해하고 있자.
• errorArgs: 오류 메시지에서 {0}를 치환하기 위한 값
• defaultMessage: 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지

📌 reject()

---

[11] 오류 코드와 메시지 처리3

오류 코드는 "상품 이름은 필수입니다."와 같이 자세할 수도, "필수 값 입니다."와 같이 단순할 수도 있다.

단순하게 만들면 범용성이 좋아 여러 곳에서 사용할 수 있지만 세밀히 작성하기엔 어렵다. 반대로 너무 자세하면 범용성이 떨어진다.
그래서 가장 좋은 방법은 범용성으로 사용하다 필요할 때만 세밀한 내용이 적용되도록 만들면 된다.

(우선 객체명과 필드명을 조합한 메시지가 있는지 확인하고, 없다면 좀 더 범용적인 메시지를 선택하도록)

---

[12] 오류 코드와 메시지 처리4

📌 MessageCodesResolver:
검증 오류 코드로 메시지 코드들을 생성
MessageCodesResolver 인터페이스, DefaultMessageCodesResolver는 기본 구현체
주로 ObjectError, FieldError와 함께 사용

📌 MessageCodesResolver의 기본 메시지 생성 규칙

• 객체 오류의 경우 다음 순서로 2가지 생성

1. error code + "." + object name
2. error code

ex. 오류 코드: required, object name: item
1. required.item
2. required

• 필드 오류의 경우 다음 순서로 4가지 메시지 코드 생성

1. error code + "." + object name + "." + field
2. error code + "." + field
3. error code + "." + field type
4. error code

ex. 오류 코드: typeMismatch, object name "user", field "age", field type: int
1. "typeMismatch.user.age"
2. "typeMismatch.age"
3. "typeMismatch.int"
4. "typeMismatch"

동작 방식

• rejectValue(), reject()는 내부에서 MessageCodesResolver(여기에서 메시지 코드들 생성)를 사용한다.
• FieldError, ObjectError의 생성자를 보면 오류 코드를 여러개 가질 수 있다. MessageCodesResolver를 통해 생성된 순서대로 오류 코드를 보관한다.

오류 메시지 출력
타임리프 화면을 렌더링 할 때 th:errors가 실행되고 이때 오류가 있다면 생성된 오류 메시지 코드를 순서대로 돌아가며 메시지를 찾고 없다면 디폴트 메시지를 출력한다.

---

[13] 오류 코드와 메시지 처리5

구체적인 것에서 ➡️ 덜 구체적인 것으로

MessageCodesResolver는 required.item.itemName처럼 구체적인 것을 먼저, 그리고 required처럼 덜 구체적인 것을 가장 나중에 만든다.

ex. itemName의 경우 required 검증 오류메시지 발생시 다음 순서대로 메시지가 생성
1. required.item.itemName
2. required.itemName
3. required.java.lang.String
4. required
이렇게 생성된 메시지 코드를 기반으로 1번부터 순서대로 MessageSource에서 메시지를 찾는다.

📌 ValidationUtils

        // 검증 로직
        if(!StringUtils.hasText(item.getItemName())) {
            bindingResult.rejectValue("itemName", "required");
        }

를 아래와 같이 한 줄로 대체 가능.
제공하는 기능 = Empty, 공백 같은 단순한 기능만 제공

        ValidationUtils.rejectIfEmptyOrWhitespace(bindingResult, "itemName", "required");        

📌
1. rejectValue() 호출
2. MessageCodesResolver를 사용해 검증 오류 코드로 메시지 코드들 생성
3. new FieldError()를 생성하며 메시지 코드들을 보관
4. th:errors에서 메시지 코드들로 메시지를 순서대로 메시지에서 찾고 노출

---

[14] 오류 코드와 메시지 처리6

검증 오류 코드는 개발자가 직접 설정한 오류 코드 (rejectValue() 직접 호출)과 스프링이 직접 검증 오류에 추가한 경우(주로 타입 정보 맞지 않음)으로 나눌 수 있다.

타입 오류의 경우 typeMismatch라는 오류 코드를 사용하는데 이 오류 코드는 스프링이 제공한 것

---

[15] Validator 분리1

목표: 검증 로직 분리하기

📌 검증을 체계적으로 제공하기 위해 스프링이 제공하는 인터페이스

public interface Validator {
    boolean supports(Class<?> clazz);
    void validate(Object target, Errors errors);
}

supports() {}: 해당 검증기를 지원하는지 여부 (바로 다음 [16]에서 이해할 수 있음)
validate(Object target, Errors errors): 검증 대상 객체와 BindingResult

---

[16] Validator 분리2

WebDataBinder: 스프링의 파라미터 바인딩의 역할을 해주고 검증 기능도 내부에 포함. 여기에 검증기를 추가하면 해당 컨트롤러에서 검증기를 자동으로 적용할 수 있음.
@InitBinder: 해당 컨트롤러에만 영향을 줌. 글로벌 설정은 별도 필요.

v6에서는 검증 대상 앞에 @Validated를 붙여 검증기를 직접 호출하는 부분을 없앴다.
@Validated: "검증기를 실행하라"
이 애노테이션이 붙으면 WebDataBinder에 등록한 검증기를 찾아 실행한다. 그런데 검증기가 여러개일 경우 어떤 걸 실행해야 할지 몰라 이때 필요한 것이 앞서 얘기했던 supports()이다.

📌
@Validated = Valid

대신 @Valid를 사용하려면 build.gradle 의존관계 추가가 필요.
이는 자바 표준 검증 애노테이션이고 @Validated는 스프링 전용 검증 애노테이션

---

유독 이번 강의는 머리에 잘 정리가 안돼서 힘들었던 챕터
나중에 따로 정리를 해둬야 할 것 같다.