아래는 "키워드 랭킹 API" 예시(일간/주간/월간)를 중심으로,

컨트롤러서비스DTO 설계를 어떻게 할지에 대한 전략을 단계별로 정리한 것입니다.

다양한 상황에서 실무 코드가 어떻게 변할 수 있는지, 각 방식의 장점/단점 그리고 적합한 시나리오를 함께 살펴보겠습니다.

1️⃣ 직접 파라미터를 Controller에서 받아, Service에 직접 전달 (DTO 없이)

A. 시나리오/구현

java
복사편집
@GetMapping("/daily")
public ResponseEntity<KeywordRankingListResponseDto> getDailyRanking(
        @RequestParam(required = false) String platform,
        @RequestParam String currentTime
) {
    Platform enumPlatform = Platform.valueOf(platform);
    KeywordCategory category = KeywordCategory.valueOf("전체");
    return ResponseEntity.ok(
        trendingService.getRealtimeByFilterDays(1, enumPlatform, category, currentTime)
    );
}

@GetMapping("/weekly")
public ResponseEntity<KeywordRankingListResponseDto> getWeeklyRanking(
        @RequestParam(required = false) String platform,
        @RequestParam String currentTime
) {
    // 거의 동일, days만 7
    Platform enumPlatform = Platform.valueOf(platform);
    KeywordCategory category = KeywordCategory.valueOf("전체");
    return ResponseEntity.ok(
        trendingService.getRealtimeByFilterDays(7, enumPlatform, category, currentTime)
    );
}

• 서비스 메서드:

  java
  복사편집
  public KeywordRankingListResponseDto getRealtimeByFilterDays(
      int days, Platform platform, KeywordCategory category, String currentTime
  ) {
      // ...
  }
  
  

B. 장점

1. 단순 & 직관: 파라미터가 많지 않을 땐 이해하기 쉬움.
2. 빠른 개발: 작은 프로젝트나 프로토타입에서 빠르게 구현 가능.
3. 성능 부담 적음: DTO 변환 로직이 없으니(미미한 차이지만) 코드도 짧고 단순.

C. 단점

1. 중복 코드: 일간/주간/월간/실시간 등등 API가 늘어나면 Controller에 비슷한 코드가 반복.
2. 파라미터 증가 시 관리 어려움: 파라미터가 5~10개 이상 많아지면, 메서드 시그니처가 복잡해지고 가독성이 떨어짐.
3. 검증(Validation) 어려움: 파라미터별 유효성 검사 로직을 Controller에서 따로 처리해야 함.

D. 적합 상황

• 파라미터가 매우 적고(2~3개 수준), API가 많지 않은 간단한 프로젝트
• 초기 스켈레톤이나 PoC(Proof of Concept) 단계