본 프로젝트 자료는 김영한님의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술을 참고 제작됐음을 알립니다.
Form 전송 객체 분리 란?
Bean Validation-groups 을 실제 개발을 시작할 때 잘 사용하지 않는다고 한다.
그 이유는 등록 시 폼에서 전달하는 데이터가 설계한 도메인 객체와 맞지 않다고 한다.
- groups 단점
- 간단한 경우에만 적용할 수 있다. 수정시 검증이 중복될 수 있고, groups를 사용해야 한다.
그래서 실제로 많이 사용되는게 Form 전송 객체 분리 원리를 사용해서 분할 시켜 작업한다.
폼 데이터 분리 전달에 대한 장단점
- 장점: 전송하는 폼 데이터가 복잡해도 거기에 맞춘 별도의 폼 객체를 사용해서 데이터를 전달 받을 수
있다. 보통 등록과, 수정용으로 별도의 폼 객체를 만들기 때문에 검증이 중복되지 않는다. - 단점: 폼 데이터를 기반으로 컨트롤러에서 Item 객체를 생성하는 변환 과정이 추가된다.
Form 전송 객체 분리 활용
groups 와 어떠한 점이 다른지 사용하는 이유를 알아볼려고 한다.
일단 groups 사용을 위해 등록된 검증 코드를 제거
검증 코드를 삭제했으니 별도의 저장용 폼과 수정용 폼을 만들어 줘야 한다.
ITEM 저장용 폼
ITEM 수정용 폼
저장과 수정폼을 등록했으면 내부 로직들도 작동할 수 있게 정리해줘야 한다.
수정 전
수정 후
수정 전
수정 후
- Item 대신에 ItemSaveform 을 전달 받는다.
- 이렇게 설계하면 @Validated 로 검증도 수행하고, BindingResult 로 검증 결과도 받는다.
- @ModelAttribute("item") 에 item 은 itemSaveForm 의 model 로 담기게 된다.
Bean Validation - HTTP 메시지 컨버터
@ModelAttribute 는 HTTP 요청 파라미터(URL 쿼리 스트링, POST Form) 를 다룰 때 사용한다고 한다.
PostMan 을 사용해서 테스트 해볼려고 한다.
PostMan
지금 오류같은 경우 HttpMessageConverter 에서 요청 JSON을 ItemSaveForm 객체로 생성하는데 실패해서 그렇다. 원인은 price의 경우 Integer 로 숫자로만 받을 수 있는데 문자가 들어와 Validation 에서 정보를 받지 못해서 생긴 오류라고 보면 된다.
위 같은 오류는 설정한 오류 범위 이내로 틀린 정보를 입력했기에 오류 정보를 출력해서 보여주는 모습을 확인할 수 있다. 전부 다 사용자가 입력한 결과 값으로 출력해주고 있다.
실제 개발할 때는 이 객체들을 그대로 사용하지 말고, 필요한 데이터만 뽑아서 별도의 API 스펙을 정의하고 그에 맞는 객체를 만들어서 반환해야 한다.
