МФ
я не работал в 500, максимум 80, но общался с большинством исключительно на кухне или корпоративе
Size: a a a
2021 May 11
R
Что значит "зарегистрировать в DI"? Мы же не про DI контейнер говорим, а про DI как реализацию Dependency Inversion
AK
DI как dependency inversion имеет аббревиатуру DIP, а DI это обычно именно dependency injection
R
DI — это DI. А автоматический резолвинг зависимостей — это контейнер
AK
это исключительно чтобы путаницы меньше было
SP
DI - это реализация IoC. DIP это про изменение направлений зависимостей через интерфейсики
AK
а, ну так сразу все понятно “di - это di” лучше не придумаешь)
SP
"отделять сервисы о трепозиториев" - это абстрактные сказки про "счастье в слоях". Потом смотришь на эти "репозитории" с 50+ методов и грустишь
R
Плохо можно написать везде. 50+ методов в репозитории, это очевидное пренебрежение ISP
R
Разница только в том, что если не отделять репо от сервиса, то эти 50+ методов добавляются к сервису
R
При условии, что это пишет тот же программист
AK
под “отделять” подразумевается в аннотации типа(тайп хинте) указывать интерфейс, а не класс-реализацию?
SP
ну вот тебе пример. Есть у тебя задача - надо трекать текущее местоположение пользователя (например курьера трекать показывать на карте). Зачем тут репозиторий?
R
И самый упоротый случай — логика сохранения размазывается по бизнес-логики
R
Не, это разделять вещи на две сущности. Интерфейс можно выделить как сразу, так и позже через Refactor -> Extract Interface
R
Если сервису не нужна персистентность — репозторий не нужен, да. Это вырожденный пример
SP
в смысле не нужна? надо хранить историю перемещений, надо доставать из стораджа.
SP
ты будешь делать "репозиторий"?
SP
а что тогда будет "в сервисе"?
SP
другой пример. У тебя есть задача делать профиль юзера. Тупой круд. Зачем нам там сущности или репозитории?