[FEAT/#297] 배너 목록 조회 기능 구현

[yummygyudon]

Related Issue 🚀

• closed [FEAT] 배너 - 목록 조회 #297

Work Description ✏️

• 배너 목록 조회 기능 구현

PR Point 📸

※ Request Parameter 처리

현재 구현된 방향성은 아래와 같습니다.

• Service 인터페이스에 "정렬 기준"(Sort Criteria) / "분류 기준"(Filter Criteria) Enum 클래스를 선언했습니다.
  • 외부의 입력값에 대해 Service 구현체 내부에서 변환하는 것은 "책임이 분리되지 않은 것"이라고 판단했습니다.
  • Controller 단에서 "요청 값 → 비즈니스 로직 가용 값" 변환이 필요하다고 판단했습니다.
  • Criteria Enum의 경우, #fromParameter라는 비즈니스 로직 가용 값으로 전환하는 static method를 제공합니다.

※ 시스템 시간 의존성 제거

주로 요청 시점 기반 동적 연산이 필요한 경우, LocalDate.now()/LocalDateTime.now()를 통해 현재 시간에 대한 데이터를 조회하게 됩니다.
하지만 위와 같이 구현한 경우, 특정 날짜 값과의 연산이 필요한 기능에 대해 Test를 진행하면 에러가 발생할 확률이 높아진다고 생각합니다.
(실제로 CI 단계에서 에러가 발생하는 것을 발견했습니다.)

이에 따라 Clock 객체 주입을 통한 LocalDate.now()/LocalDateTime.now() 호출 방식으로 변경해 해결했습니다.
이로써 얻게 된 효용은 아래와 같습니다.

• 테스트 진행 시, 테스트에서 의도한 기준 날짜 기반으로 테스트를 진행할 수 있습니다.
• 현재 시스템 상의 시간에 의존적인 코드 구현을 방지할 수 있습니다.

※ DB 조건부(where / order by) 조회 vs Stream 중간 연산 (filter / sorted)

현재 구현 방식은 후자인 "Stream 중간 연산 (filter / sorted)"을 채택한 방식입니다.

Application ↔ DB 간 네트워크 속도 최적화 & 할당되는 메모리 절약을 위해 DB에서 최대한 필터링하는 것이 가장 바람직하지만

• 현재 데이터 양은 많지 않은 상황
• 빠른 구현이 필요한 상황

위 두 상황을 이유로 본 작업 내용과 같이 구현하게 되었습니다.

이에 따라 추후에 DB 쿼리를 통해 필요한 데이터만 조회할 수 있도록 개선할 계획입니다.

• 참고 링크 1
• 참고 링크 2

※ 페이지네이션(Pagination)에 대한 고민

이 또한 위 내용과 동일한 상황적 이유와 함께 "단순 기본형 타입 필드로 구성된 객체"라는 이유로 별도 페이지네이션 처리에 대해선 구현하지 않고 전체 배너 정보 리스트를 반환하도록 했습니다.
(+JPA Pagable 전용 메서드까지 추가적인 구현이 필요하기 때문)

하지만 추후 게시하는 배너가 누적될수록 데이터의 양이 방대해지기 때문에 페이지네이션을 고려할 필요가 있습니다.
이에 따라 추후 JPA Pagable 적용을 계획하고 있습니다.

• 실제 배포 이후 "변경이 적다"라고 관측된다면 "전체 리스트 Cache" 혹은 "페이지 별 Cache"를 고려하는 것도 좋아보입니다.
  • 참고 링크 - 단, 성능 개선 여부는 확인이 필요해보입니다. (Cache를 위한 메모리 할당 vs 조회 시간 단축 Trade-Off 필요)

[height]

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[sung-silver]

PR 꼭 자세하게 써주기~~! 일단 머지하세용