Д
несовсем понятно как тут устроено у него..
детали уже не суть, ок, для простоты представим проще
Есть контроллер, он дёргает некий класс, где по связям вытаскиваются книги и авторы
Size: a a a
2021 April 27
VV
Важен сам принцип, как действовать когда тебе нужно подменить реализацию конкретного интерфейс в конкретном контроллере. При том, что меняется только данные в ответе и то, как эти данные получать. Но сама логика не меняется, ни особо формат ответа (DTO ответа допустим может измениться)
VV
с одной стороны я понимаю, что конфигурировать контейнер в контроллере не лучшее занятие, но с другой, зачем использовать контейнеры, если ради такой простой подмены, придётся прокидывать всю зависимость вглубь с самого верха.
Т.е. моё решение оно рабочее, вопрос только к дизайну
Т.е. моё решение оно рабочее, вопрос только к дизайну
ES
Получается что у тебя книга знает откуда доставать автора
Вроде как напрашивается сервис ответственность которого была бы доставать авторов из конкретного места принимая на вход книгу
Быть может из того что есть сервиса сделать базовый с методом getAuthor()
А в BookLitresService переопределить его просто и все
Вроде как напрашивается сервис ответственность которого была бы доставать авторов из конкретного места принимая на вход книгу
Быть может из того что есть сервиса сделать базовый с методом getAuthor()
А в BookLitresService переопределить его просто и все
T🐜
В уии2 контейнер для галочки скорее. Возможностей у него раз два и обчелся.
VV
Книга не знает КАК достать, но она знает, что их можно достать через класс Авторы. Стандартная работа связей Yii. Связи это удобный и простой способ получения связанных данных. Но не в этом суть.
Хорошо, допустим у нас нет связей, есть BookService и BookLitresService, авторы всё равно будут лежать в другом классе. Как и главное где это всё конфигурировать?
Хорошо, допустим у нас нет связей, есть BookService и BookLitresService, авторы всё равно будут лежать в другом классе. Как и главное где это всё конфигурировать?
VV
работу он свою делает, классы разруливать умеет. Смотрел ларавел di, там уже слишком много
T🐜
Ну, ты уже на своем опыте ощутил дефицит возможностей.
VV
нет, работать то я его заставил. Вопрос скорее организационный
ES
Кого конфигурировать? У тебя конкретный сервис будет принимать объект авторов и будет знать что нужно достать данные по апи, на сколько я понял
ES
Конкретный сервис знает куда лезть за данными
VV
но я то получаю книги (BookService), через которые как-то внутри получаются авторы
ES
Ну так сделай сервис через который ты получаешь авторы
Д
тебе нужно сделать контракт тогда AuthorServiceInterface , а нужну его реализацию совать в BookService
ES
Слушай а у тебя такая структура вложенности получилось а теперь ты не знаешь как с ней работать
Д
вот да.. слои слои. и непонятно зачем
VV
не слои, а объекты, а не классы. не DDD, но очень приближенные к бизнесу язык
ES
А как у тебя так получается что у тебя сущность авторы насколько я понимаю вытягивается с базы данных и она же лезет в апи
VV
Я к тому, в чём выгода DI, Если зависимости всё равно прокидывать рукамии?