a
Controller::showData
выполнение запроса к сервису, получение этих данных в виде массива объектов, отдаем на фронт в виде json
Service:getData
запрос к DAO на получение данных, отдаем контроллеру
DAO:getData
получение данных в виде двумерного массива из источника, преобразование в массив объектов типа EntityDTO, отдаем сервису
EntityDTO implements JsonSerializable
обёртка над массивом, есть возможность сетать произвольные свойства. Реализован магический __get, который может возвращать значения если есть метод get*****.
Вопрос такой: хочу в результирующем json в у каждого entity иметь дополнительное поле с урлом paymentUrl. Генерация paymentUrl имеет признак бизнес-логики: в зависимости от поля Creditor ссылка на оплату ведет на разные сайты.
На каком уровне обработки генерировать и сетать этот урл?
Возможные варианты:
1. В контроллере - Получаем массив DTO-шек, через foreach сетаем DTOшке урл. Как понимаю, это плохой подход: бизнес-логику в контроллер лучше не пихать, чтобы не распухали
2. На уровне сервиса. foreach + сет.
3. На уровне DAO. foreach + сет. Но это не обязанность DAO, поэтому такой вариант не принимаем.
4. На уровне DTO. Объявляем геттер getPaymentUrl и логику кладём в него. Видится, что это тоже плохой подход, DTOшка тоже не должна иметь бизнес логики.
Правильно ли понимаю, что лучше всего переложить генерацию этого урла на сервис? Все остальные компоненты не подходят ввиду специфики: бизнес-логика и работа с урлами. Например, работать с менеджером урлов фреймворка из DTOшки или DAO - это очень плохо.