Зачем нужно делать отдельный контроллер для получения каждого отчета?

Отдельные контроллеры для каждого отчета: архитектурный подход

Суть вопроса

Вопрос касается архитектурного паттерна построения API, где вместо создания универсального контроллера для всех отчетов создаются отдельные контроллеры для каждого типа отчета.

Основные причины

1. Принцип единственной ответственности (Single Responsibility Principle) Каждый контроллер отвечает только за логику одного типа отчета. Это делает код:

• Проще понять и поддерживать
• Легче тестировать
• Менее подвержено ошибкам при изменениях

2. Различные требования для разных отчетов Каждый отчет может иметь:

• Уникальные параметры фильтрации
• Разные форматы вывода (JSON, CSV, PDF)
• Различные права доступа
• Специфическую валидацию данных

// Вместо универсального подхода:
@Controller('/reports')
class ReportController {
  @Get(':type')
  getReport(@Param('type') type: string) {
    if (type === 'sales') { /* ... */ }
    if (type === 'analytics') { /* ... */ }
  }
}

// Правильный подход:
@Controller('/reports/sales')
class SalesReportController {
  @Get()
  getSalesReport() { /* логика */ }
}

@Controller('/reports/analytics')
class AnalyticsReportController {
  @Get()
  getAnalyticsReport() { /* логика */ }
}

Преимущества

• Масштабируемость: новый отчет = новый контроллер, без изменения существующего кода
• Переиспользуемость: каждый контроллер может использовать свой набор сервисов
• Тестируемость: изолированные юнит-тесты для каждого отчета
• Документация: явные эндпоинты легче документировать (Swagger/OpenAPI)
• Производительность: оптимизированные запросы к БД для конкретного отчета

Когда использовать объединённый подход

Если отчеты имеют идентичную логику обработки, можно использовать параметры:

@Controller('/reports')
class ReportController {
  @Get(':format')
  getReport(@Param('format') format: 'json' | 'csv') {
    // одна логика, разные форматы
  }
}

Но это исключение, а не правило.