AM
Как ей решать, биндингом или много-контейнерностью — вопрос. Я склоняюсь к биндингу. Так немного проще как в реализации, так и для восприятия юзера.
Size: a a a
2021 January 29
NO
AM
Не, не меньше. Тебе надо будет хранить разные инстансы для разных скоупов. Плюс контейнер будет стрикт, то есть все сервисы/классы должны быть прописаны, так как тебе надо знать скоуп сервиса/класса. Плюс ещё там есть проблемы, но я так сразу не скажу, давно этим занимался.
Конечно надо будет хранить разные. Как и в случае с множественными контейнерами.
NO
Биндить норм. Даже заглушку вкорячить временную пригодится, например.
AM
Прописывать всё необходимости нет. Не прописано — скоуп дефолтный.
AM
Биндить норм. Даже заглушку вкорячить временную пригодится, например.
Ты только что говорил что не норм на примере двух кешей :)
DS
Прописывать всё необходимости нет. Не прописано — скоуп дефолтный.
В модулях придётся все.
AM
В модулях да.
AM
Но это всё-равно чуть понятней, чем вложенные контейнеры, как по мне...
DS
Конечно надо будет хранить разные. Как и в случае с множественными контейнерами.
И это вызывает те же проблемы. Эти два подхода похожи, и проблемы там те же
AM
Ты про глубокие зависимости?
NO
Ты только что говорил что не норм на примере двух кешей :)
Не норм жахнуть подмену "типа глобально" на уровне контейнера и вести разные контейнеры для модулей. Потому что там жесть начнётся.
В случае биндинга можно различать глобальную и переопределённую реализацию, и отладке будет поддаваться.
В случае биндинга можно различать глобальную и переопределённую реализацию, и отладке будет поддаваться.
DS
Ты про глубокие зависимости?
И про них тоже, там в контейнере есть мой пр с тестами, который показывает какие кейсы не работают для контейнера модуля. Правда, с тех пор контейнер прилично поменяли, надо будет смотреть как изменилась ситуация.
AM
И про них тоже, там в контейнере есть мой пр с тестами, который показывает какие кейсы не работают для контейнера модуля. Правда, с тех пор контейнер прилично поменяли, надо будет смотреть как изменилась ситуация.
Записать бы это всё списком в gist...
AM
Не норм жахнуть подмену "типа глобально" на уровне контейнера и вести разные контейнеры для модулей. Потому что там жесть начнётся.
В случае биндинга можно различать глобальную и переопределённую реализацию, и отладке будет поддаваться.
В случае биндинга можно различать глобальную и переопределённую реализацию, и отладке будет поддаваться.
Биндинг в этом плане ничем не отличается от суб-модуля.
AM
"магически" в один набор классов подставляется одно, а в другой — другое
DS
Записать бы это всё списком в gist...
Это пока не приоритетная задача. Модули можно и так делать, пихая все в один контейнер и переопределяя контекст поклассово.
AM
Это пока не приоритетная задача. Модули можно и так делать, пихая все в один контейнер и переопределяя контекст поклассово.
Согласен.
NO
Как ей решать, биндингом или много-контейнерностью — вопрос. Я склоняюсь к биндингу. Так немного проще как в реализации, так и для восприятия юзера.
Без этой "фичи" можно разрабатывать приложения и модули?
AM
Конечно.