[4기 - 안재영] SpringBoot Part3 Weekly Mission PR 제출합니다.

[JaeyoungAhn]

📌 과제 설명 및 요구사항

• SpringBoot Part3 Weekly Mission(~7/14)

(기본) 바우처 서비스 관리페이지 개발하기

• Spring MVC를 적용해서 thymeleaf 템플릿을 설정해보세요.
• 커맨드로 지원했던 기능을 thymeleaf를 이용해서 관리페이지를 만들고 다음 기능을 지원가능하게 해보세요
  • 조회페이지
  • 상세페이지
  • 입력페이지
  • 삭제기능

(기본) 바우처 서비스의 API 개발하기

• Spring MVC를 적용해서 JSON과 XML을 지원하는 REST API를 개발해보세요
  • 전체 조회기능
  • 조건별 조회기능 (바우처 생성기간 및 특정 할인타입별)
  • 바우처 추가기능
  • 바우처 삭제기능
  • 바우처 아이디로 조회 기능

구조 및 흐름

👩‍💻 구현 내용

2주차 피드백 반영

refactor : 콘솔 실행 관련 클래스 위치 view 밖으로 이동

refactor : GlobalExceptionHandler 패키지 변경

rename : 가독성 향상을 위해 enum class 내 변수명 변경

refactor : 가독성을 위해 short이 아닌 int 타입으로 데이터를 다루도록 변경

refactor : null 관련 검증 코드 추가

refactor : 추후 테스팅 용이성을 위해 추상화 된 UUID 생성 클래스를 주입하는 것으로 변경

refactor : NumberFormatException을 Global Exception Handler에서 에러 처리하도록 변경

fix : UUID Generator 수정에 따라 제어 요구사항이 필요하지 않은 테스트 코드 수정

refactor : 일부 익셉션을 @ControllerAdvice를 통해 처리하도록 변경

---

3주차

feat : @ControllerAdvice를 이용한 글로벌 익셉션 핸들링

feat : 바우처 도메인 관련 json, xml, thymeleaf 지원

✅ PR 포인트 & 궁금한 점

프로젝트 전체적으로 문제는 없는지 궁금합니다!

validation은 NullPointerException을 내지 않게끔 하는 것에서 충분한지 아니면 더 많은 검증을 해야하는지 궁금합니다. 예를 들어서 DTO에 시작 시간, 끝 시간 두 가지가 LocalDateTime이라는 타입으로 들어오는데, 이것이 null이 아닌 것을 조사하는 것에서 끝나지 않고 더 나아가서, 끝 시간이 시작 시간보다 뒤에 있다는 것을 검증해주는 것이 맞는지 고민이 되는데, 여기서 더 나아가서 그렇다면 애초에 년도 데이터 형식이 올바른지도 검증을 해야할 것 같고, 더 나아가서 이제 2023년인데 2024년 2022년 같은 원치않는 데이터가 들어오면 어떻게 해야하는지와 같은 끝이 없는 고민을 하게 되는 것 같습니다.