MV
персист есть в репе - ->save(entity) вроде
Size: a a a
2021 April 16
АЯ
Смотри, некоторые рекомендации работают только вкупе с другими. Бывает код неправильно организован вцелом, тогда приходится делать неправильно.
MV
допустим в классе, где я создаю новую сущность мне нужно получить что-то из другой сущности.
АЯ
Ну получай, флашить то зачем?
MV
понимаю, но флашить в других местах будет как-то не особо ок. этот клсс самое оно для этого, хз как лучше объяснить)
АЯ
"Не использовать ЕМ" не означает просто взять у себя в коде и заменить на репы. Это озачает "реорганизовть архитектуру так, чтоб не приходилось использовать ЕМ"
MV
ладно, окей. а кто-то может мне все таки сказать, что плохого в локаторе?
MV
типа getRepo() - сервис локатор, ок, а что плохого?
АЯ
В самом по себе локаторе плохо то, что ты привязываешь сущность к конкретному ЕМ.
АЯ
А у тебя их может меняться или быть несколько.
MV
не понел
MV
давай оторвемся от сервис локатора в getRepository(), что плохого в локаторе?)
АЯ
Ну вот сущность "юзер" к примеру. Может лежать в БД, её можно переложить в другое место, можно вообще не хранить на проекте а запрашивать, к примеру, у лдап сервера
АЯ
В том что это прото свалка всего подряд, а не чётко определённые зависимости.
АЯ
Вытягивание из локатора равнозначно дёрганию статики.
MV
и что в этом плохого, если оно в контейнере?
АЯ
Нарушение иерархии зависимостей. И неявная магия
MV
ну неявная магия тут кругом какб
АЯ
В идеале в твоём классе ты вообще не запрашиваешь ни контейнер ни локатор, а работаешь с тем что тебе пришло в депенденсях
MV
но удобно же руллить эти депенденсы локаторами