нем много параметров? Один метод из-за этого создает спагетти код с кучей if else, где идет обращение к разным сервис методам в завимости от переденных request param:)
Ну можно создать класс, который будет содержать в себе все поля и смапить реквест на него
И если в if/else идет какая-то валидация, то ее вынести в отдельный класс
там идет проверка на существование определенных параметров
А параметры по смыслу как-то связаны?)
ну например такие параметры: offset/limit, dateFrom/dateTo, idList1, idlist2, в некоторых есть валидация по типу @Positive, @Max, есть где-то дефолтные значения и тд
По-моему проблема тут в том, что у вас метод "швейцарский нож")
Валидатор и @AssertTrue методы валидации на различные параметры
Сделать разные эндпоинты или реализовать стратегию
Динамическая фильтрация что ли?
это значит что у вас один контроллер там, где должно быть много, либо много сервисов там, где должен быть один
ну извините, не я решал сколько будет ендпоинтов :) И в чем плохого в гибком ендпоинте?
ну решите теперь сейчас сами
сменить контракт ендпоинта которым пользуется куча сервисов?
Выкати новую версию сервиса и обозначь для потребителей сроки переезда
так все просто?) Может еще и бизнесу сказать что они лохи и нужно по-другому?😁
Объясни что поддерживать старое говно для них будет куда дороже
а как стоит такой ендпоинт разбить? Типо отдельно offset/limit, отдельно idList/offset/limit, отдельно idsList1/idList2/offset/limit, а там еще и limit/offset/dateFrom/dateTo?
Надо смотреть что конкретный параметр делает. Может там подойдёт и вариант как выше писали в объект с валидацией засунуть
это про аргумент метода, но ведь еще есть проблема ifelse в теле, которую то решение не исправит
Обсуждают сегодня