AM
Не конструктивненько :)
Size: a a a
2021 January 29
NO
Вот только конкретики из него выпытать не удаётся :)
Да по конкретике мы с тобой по конфигам уже схему разбирали. Ты сказал "выглядит сносно, нужен код". По-моему так было...
NO
Хорошо, конструктив: нужно делать на одном контейнере, а не изворачиваться пытаясь за его счëт решить всякие проблемы.
AM
Сейчас накидываю прототип как раз.
AM
Посмотрю что из этого получится.
Д
Не понял почему тут обязательно нужно несколько контейнеров. Что мешает в одном сделать?
Нет, это нужно не обязательно, а по желанию. Хочешь так сделай, хочешь всё в одном контейнере собирай.
NO
Нет, это нужно не обязательно, а по желанию. Хочешь так сделай, хочешь всё в одном контейнере собирай.
Вопрос, если это не закладывается в основу фреймворка, зачем вам решать эту проблему?
NO
И зачем делать кучу вариантов контейнера тоже непонятно.
NO
Сделать достаточно интерфейс + пару реализаций, какую-нибудь самую простейшую и более оптимизированную для продакшена, всё. Что мудрить? )
Д
Вопрос, если это не закладывается в основу фреймворка, зачем вам решать эту проблему?
Я уже не помню, какую решали проблему изначально. Потом уже развили идею до фичи.
NO
Лишние фичи всегда боком выходят. )
Д
Не запрещать же людям развлекаться.
DS
Я уже не помню, какую решали проблему изначально. Потом уже развили идею до фичи.
Решали проблему биндинга на глобальный интерфейс разных реализаций для разных модулей. Например, глобально для приложения CacheInterface => FileCache::class, а в модуле я хочу CacheInterface => RedisCache::class. А потом побочно уже возникла фишка инкапсуляции внутренней логики модуля в локальном контейнере модуля, недоступном из приложения и других модулей.
DS
Вопрос, если это не закладывается в основу фреймворка, зачем вам решать эту проблему?
Позволяет не делать ошибки в архитектуре, когда вместо обращения к публичным интерфейсам модуля обращаются к его внутренней логике.
NO
Позволяет не делать ошибки в архитектуре, когда вместо обращения к публичным интерфейсам модуля обращаются к его внутренней логике.
Не задача фреймворка.
DS
Не задача фреймворка.
Фреймворк даёт инструмент для реализации таких модулей.
NO
Решается в проектах каким-нибудь deptrac, когда команда понимает, что есть необходимость контроля. Если команда этого не понимает, то она и без этого накостылит.
NO
Фреймворк даёт инструмент для реализации таких модулей.
Ну и плохо. Я бы выгнал сотрудника, который пытается делать всё, а не то что ему поручили.
DS
Ну и плохо. Я бы выгнал сотрудника, который пытается делать всё, а не то что ему поручили.
Ну я бы на тебя вообще не ориетировался. Тебе абы поговорить)