[5기 - 조인수] SpringBoot Part 3 Weekly Mission 제출합니다.

[ZZAMBAs]

📌 과제 설명

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

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

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

• Spring MVC를 적용해서 JSON과 XML을 지원하는 REST API를 개발해보세요

  • 전체 조회기능
  • 조건별 조회기능 (바우처 생성기간 및 특정 할인타입별)
  • 바우처 추가기능
  • 바우처 삭제기능
  • 바우처 아이디로 조회 기능

• (보너스) 바우처 지갑용 관리페이지를 만들어보세요.

👩‍💻 요구 사항과 구현 내용

Controller를 추가하여 thymeleaf에서 뷰를 보여주거나 rest api 통신이 가능하도록 하였습니다.

✅ 피드백 반영사항

part2까지 반영사항

• Voucher가 VoucherPolicy를 갖도록 하여 유동적으로 할인 정책을 적용할 수 있도록 했습니다.
• XXXDatabaseRepository에서 XXXJdbcRepository로 더 명확한 이름으로 바꾸었습니다.
• wallet을 도메인에서 제외하고 customer와 voucher를 연결해주는 customers_vouchers 테이블을 만들었습니다.
• 테스트 코드에 @DisplayName()을 붙여 어떤 테스트인지 알기 쉽도록 한 곳도 있습니다.

part3 반영 사항 (2023-11-18)

• 도메인에서 DTO로 변환하는 작업의 경우, 이번 프로젝트는 작은 프로젝트였기 때문에 따로 mapper 클래스 생성 없이 DTO 내부에서 변환 로직을 생성했습니다. (VoucherResponseDto 내부 convertVoucherToVoucherResponseDto() 메서드)
• 서비스가 더이상 도메인을 반환하지 않습니다. 이는 컨트롤러 레이어에서 도메인에 대한 접근을 막기 위해 적용하였습니다. 바우처 필터링은 일단 컨트롤러에서 쿼리 파라미터로 각 필드를 받고 그것을 VoucherFilterDto로 변환한 뒤, 서비스에 전달합니다. 즉, 컨트롤러와 서비스 사이에서도 Dto를 적용합니다. 역시나 Voucher라는 도메인 자체를 컨트롤러에 숨기기 위함이며, 서비스에서도 필요한 정보만 파라미터로 받을 수 있게 되었습니다.
• 목 객체를 사용해 Voucher API 컨트롤러 테스트를 단위 테스트로 만들었습니다. 이에 따라 빠른 테스트가 가능하며, 컨트롤러 자체에만 집중할 수 있는 테스트가 되었습니다.

(2023-11-19)

• MVC 모델은 서로서로 상호작용을 하는 것처럼 보이지만 실질적으로 의존관계를 따져보면 아래 그림처럼 이루어집니다.
  
  DTO의 영역을 Model 영역으로 생각하여 Controller 패키지에 존재했던 DTO들을 Service 패키지로 전부 이동시켰습니다. 이제 VoucherService에서 Controller 부분과 의존하는 부분은 존재하지 않게 됩니다. 이에 따라 컨트롤러에서의 수정이 모델에 아무 영향을 끼치지 않을 것을 기대할 수 있습니다.
• VoucherService에서 insert, update 메서드는 필드를 직접 받았었으나, 지금은 DTO를 받도록 하였습니다. 나열되는 파라미터를 깔끔히 정리하기 위함도 있고 의미 전달도 객체로 명확히 할 수 있을 것이며 만약 같은 DTO를 받는 메서드가 생기면 재사용이 가능할 것 같아서입니다.

✅ PR 포인트 & 궁금한 점

• 서비스 계층의 파라미터를 DTO로 받는 방식과 컨트롤러에서 필드로 변환한 뒤 그것을 파라미터로 받는 방식 중 어느 것을 더 선호하시나요? 예를 들어 insert(Dto dto) 와 insert(VoucherType voucherType, long discountDegree) 이런 식입니다!
• View-Controller 사이 DTO는 controller 패키지에, Controller-Service 사이 DTO는 service 패키지에 넣었는데 괜찮은 선택일까요?
• 처리하는 필드가 다를 때마다 DTO를 만들어야 할까요? 이를 테면 만약 제가 Service의 insert와 update 메서드를 만들었다고 했을 때, update는 insert와 달리 ID 값을 더 필요로 할 것 같습니다. 그 외 필드는 동일할텐데 이 ID 하나 때문에 InsertDto, UpdateDto를 따로 만들어서 관리를 해야 할까요?

(2023-11-19)

• VoucherRepository에 upsert 메서드가 구현되어 있고 그 메서드에서는 VoucherRepository의 findById()를 호출하여 select 문으로 검색하여 있으면 UPDATE, 없으면 INSERT를 합니다. 그런데 VoucherService의 메서드는 insert()와 update()로 나누어서 생성하였고, insert는 문제가 없는데 update는 일단 서비스 로직 내에서 findById()를 실행하고 해당하는 Voucher가 존재하면, 다시 VoucherRepository의 upsert() 메서드를 실행하는데 역시나 여기서 또 select 문을 실행합니다.
  찾는 쿼리가 2번이나 나가는데, 설계부터 문제가 있는건지 아니면 다른 해결법이 있는지 궁금합니다. 그냥 VoucherRepository 내 메서드를 upsert()에서 insert(), update()로 나누어야 할까요?
  아래 코드에 관련 코멘트를 남겼습니다!

[ZZAMBAs]

1. 이 부분에서 update를 위해 실제 DB에 해당하는 Voucher가 존재하는지 확인합니다.

[ZZAMBAs]

2. 그런데 여기서 또 다시 확인합니다. VoucherRepository 내 upsert() 메서드를 insert(), update()로 나누는 것이 좋을까요?

[SangHyunGil]

upsert가 필요하다면 굳이 나눌 필요 없이 이를 활용해도 좋을 것 같아요 👍

[SangHyunGil]

3주차 과제까지 반영해주시느라 고생많으셨어요!
JPA때 더 열심히 달려봐요 😄