R
Если это не реалтайм, то нужно. Буду делать репозиторий. Что будет в сервисе — зависит от БЛ. Возможно, в конкретный момент это будет просто делегат. Возможно, оно так и останется. Возможно, туда добавится БЛ
Size: a a a
2021 May 11
SP
ну то есть сервис просто дергает репозиторий.
R
В конкретный момент времени — вполне. Дальше покажет БЛ
SP
ну то есть мы разводим культ карго со слоями
SP
пример с профилем юзера - сохранить там имя твое, день рождения и прочее. Бизнес логики там нет
R
Не совсем. Мы закладываем каркас
SP
каркасы снаружи должны быть)
SP
ну то есть хз зачем нужны эти каркасы
SP
больше на культ карго похоже
SP
желание "однотипно делать" как сложные вещи так и примитивный круд (шоб было)
SP
явно не дружит с YAGNI
R
Возможно ты прав. Но как показывает личный опыт, если не отделить сервис от репо, через 3 года это перерастает в такую кашу, что лучше было бы карго восхвалять
SP
ну или такой вопрос - вот эти "сервисы" - они работают с репозиториями. И там же логика так? ну то есть у нас по итогу будет что-то у чего есть зависимости + логика то есть просто так мы это юнитами не покроем
SP
это если сервисы бесконечно расширять (добавлять вещи)
SP
ну то есть Open/Close все дела
R
Почему не покроем? Сервис инстанцируется с замокаными зависимостями и тестируется
SP
мой поинт не в том что "не надо отделять репозиторий от сервиса" а в том что люди часто не оч понимают для чего они это делают и как следствие не получают по итогу профита
SP
получается какой юзер репозитори + юзер менеджер
SP
и что ты будешь тестировать?
SP
ну то есть с тестами "сервисов" обычно проблема - чем больше зависимостей тем меньше толку от юнитов