А
@roxblnfk что если сунуть в композит фабрику? :)
Не прокатит. При повторном запросе в той же сессии создастся новый объект, а не вернётся имеющийся в памяти
Size: a a a
2021 January 26
Д
Выше смотри, вы обсуждаете конфликты которые возникают от нескольких контейнеров. То есть сам факт существования такой конфигурации уже вносит сложности.
Не в этом проблема.
Проблема в хранении дто в контейнере.
Проблема в хранении дто в контейнере.
NO
По-моему принцип простоты даже в концепции третьей версии записан ) Только жаль что на практике мало используется
NO
Не в этом проблема.
Проблема в хранении дто в контейнере.
Проблема в хранении дто в контейнере.
*поперхнулся
Зачем DTO-то в контейнере хранить?
Зачем DTO-то в контейнере хранить?
Д
Вот здесь и основная проблема, и это не проблема фреймворка.
NO
Задача контейнера во внедрении зависимостей, так? При чём тут DTO?
AB
Не прокатит. При повторном запросе в той же сессии создастся новый объект, а не вернётся имеющийся в памяти
ну это получается уже стейт в контейнере хранить. в одном месте вызвать и наполнить данными, а вдругом - исползовать. магия…
Д
А контейнер модульный нужен, чтобы можно было подключать модули и делегировать получение зависимостей из других контейнеров:
И в классах модуля А понятно, что кеш будет обязательно в памяти, а логгер пусть с уровня приложения подтянется.
Так же любые определения можно "локализовать", если оно того требует. Без алиасов и копи-пасты конфига модуля в конфиг приложения.
RootContainer:
Logger
ModuleAContainer:
Cache => MemCache
И в классах модуля А понятно, что кеш будет обязательно в памяти, а логгер пусть с уровня приложения подтянется.
Так же любые определения можно "локализовать", если оно того требует. Без алиасов и копи-пасты конфига модуля в конфиг приложения.
А
ну это получается уже стейт в контейнере хранить. в одном месте вызвать и наполнить данными, а вдругом - исползовать. магия…
Вот то то и оно. Если мы будем иметь один плоский контейнер, то нельзя туда будет положить ни реквест ни респонс. А при этом разные штуки могут эти реквесты,респонсы,формы и чего там ещё, языковые настройки,... запрашивать
Д
Во всех местах использование контейнера не будет никак отличаться:
И т.п.
__construct(ContainerInterface $container)
И т.п.
А
А контейнер модульный нужен, чтобы можно было подключать модули и делегировать получение зависимостей из других контейнеров:
И в классах модуля А понятно, что кеш будет обязательно в памяти, а логгер пусть с уровня приложения подтянется.
Так же любые определения можно "локализовать", если оно того требует. Без алиасов и копи-пасты конфига модуля в конфиг приложения.
RootContainer:
Logger
ModuleAContainer:
Cache => MemCache
И в классах модуля А понятно, что кеш будет обязательно в памяти, а логгер пусть с уровня приложения подтянется.
Так же любые определения можно "локализовать", если оно того требует. Без алиасов и копи-пасты конфига модуля в конфиг приложения.
Угу, добавить свой контейнер из модуля и забить на сервис провайдеры это было бы вообще топ для некоторых вопросов
Д
Угу, добавить свой контейнер из модуля и забить на сервис провайдеры это было бы вообще топ для некоторых вопросов
Накладно выйдет)
А
Накладно выйдет)
Не так, чтобы очень
AB
Вот то то и оно. Если мы будем иметь один плоский контейнер, то нельзя туда будет положить ни реквест ни респонс. А при этом разные штуки могут эти реквесты,респонсы,формы и чего там ещё, языковые настройки,... запрашивать
ну для этого можно будет отдельные сервисы создавать: RequestStack, UnitOfWork etc. вполне себе имеют стейт
А
Но чтобы сделать все очень гибко и оптимизированно, одного пср не хватит скорее всего
А
ну для этого можно будет отдельные сервисы создавать: RequestStack, UnitOfWork etc. вполне себе имеют стейт
И куда их?
AB
Ну вот в одном контейнере и держать
А
Ну вот в одном контейнере и держать
Это на рр работать будет?
А
Сервисы ресетить придется. Симфонистайл
AB
Ну cycle на RR же работает