1. Spring Framework : validation
import javax.validation.constraints.NotEmpty; implementation 'org.springframework.boot:spring-boot-starter-validation'Form Class 또는 DTO의 필드에 @NotEmpty(message = "xxx은/는 필수 입니다.") 로 필수입력 값 validation 체크를 할 수 있다.
2. Validation Check
public String save(@Valid Form form, BindingResult result) {}Form Class 또는 DTO로 Parameter를 받을 때 @Valid 하나로 유효성검사를 편리하게 할 수 있다.
org.springframework.validation.BindingResult 객체를 함께 받아주면 에러여부(true/false)를 확인할 수 있다.
이 외에도 validation 라이브러리에 기능이 다양하기 때문에 살펴보면 좋다.회원 등록과 같은 저장 처리 후에는 redirect하는게 보편적이다.
return "redirect:/";
3.1. Entity 클래스 재활용이 아닌 Form 또는 DTO 클래스 사용 이유
Entity를 재활용하면 거기에 Validation 체크도 넣어야 하고,
그러다보면 실무에서 Entity 클래스 하나가 너무 복잡해질 수도 있음.
그렇기 때문에 받을 데이터만 가지고있는 Validation Check용도의 클래스를 따로 생성해주고 관리해주는 것이 좋음
3.2. Form 또는 DTO 활용 이유(다시 한 번 강조...)
[자주 발생하는 이슈]
Form 객체나 DTO를 따로 사용해야하나 Entity를 재사용해야하나...?실무에서 발생하는 요구사항은 대부분 Entity와 Form의 차이를 만든다.
자꾸 Entity를 재사용하다보면 Entity가 점점 화면 종속적으로 변하고 복잡해진다.
Entity는 순수하게 Entity로서의 기능에만 집중하는 것이 유지보수하기 좋다.1. Entity의 핵심 비즈니스 로직을 수정하니 화면의 기능이 망가짐 2. 화면 기능에 따라서 Entity를 수정했더니 핵심 비즈니스 로직이 망가짐조회 결과 또한, 특히 API를 만들 때는 절대로 Entity를 웹으로 반환하면 안 됨.
API는 하나의 스펙인데, 예를들면 Entity에 중요한 개인정보(주민등록번호, 비밀번호 등)가 있을 시 해당 데이터를 화면에 그대로 반환한다.
또한 Entity에 필드를 추가하게되면 API 스펙이 변함(=불완전한 API 스펙)
