AM
потому что:
1. тайпхинт
1. тайпхинт
Size: a a a
2020 March 18
А
можно предложить ещё выдавать обхекты, которые будут в контейнере WeakRef. Это что-то среднее между синглтоном и фабрикой
AM
2. резолвить руками нужно
А
вместо зависимости ты не передашь weak reference
возвращает контейнер нормальный объект, WeakRef хранит у себя
А
т.е. когда в юзерленде умирает выданный объект, то контейнер при запросе создаст новый
А
по сути берёшь обычный контейнер и дописываешь немного WeakReference
AM
а от чего он умирать-то будет?
AM
на него ссылка есть из сервиса
AM
а не из контейнера
А
напримр запросил юзера в контроллере. Пока он там висит, ты уже запросил юзера в рендере несколько раз. Это всё отрабатывает как синглтон. Потом рендер сделан, страницу возвращаешь респонсом. Тут обхект юзера умирает, т.к. нигде не хранится
А
на него ссылка есть из сервиса
тогда этот сервис не безстейтовый
AM
ну да
А
а раз так, то А - этот сервис лежит не в том контейнере или Б - этот сервис тоже в WeakContainer
AM
напримр запросил юзера в контроллере. Пока он там висит, ты уже запросил юзера в рендере несколько раз. Это всё отрабатывает как синглтон. Потом рендер сделан, страницу возвращаешь респонсом. Тут обхект юзера умирает, т.к. нигде не хранится
по мне так это ужасно
AM
непредсказуемо
DS
не, так не прокатит, ибо где-то должен же объект оседать. А если он в контейнере Weak и в дебагере Weak, то он уничтожится сразу после завершения работы конструктора ))
AM
есть у меня цепочка middleware, например
AM
я хочу пропустить по ним что-то из контейнера и модифицировать
AM
при этом после каждого шага убиваю того, кто шаг сделал
AM
ну... гипотетически