Я использую ровно такой же подход в своих проектах - ручной контейнер, в котором компоненты обернуты в LazyProvider.
Но тут есть нюанс: передача зависимостей в конструктор - это уже достаточное условие для построения графа. (Если зависимость неявная, её можно задать в библиотеке руками).
Библиотека по сути просто автоматизирует работу с этим графом:
Граф перестраивается сам при изменении кода. Добавил аргумент в конструктор - порядок запуска обновился автоматически.
Библиотека сама определяет, какие независимые ветки запускать параллельно, а где нужно ждать.
"Из коробки" есть таймауты, аварийная остановка при ошибках и тд.
Если реализовывать весь этот функционал (параллельный старт, таймауты, графовое выключение) внутри своих методов инициализации вручную - ты по факту пишешь тот же goscade, только без рефлексии, но завязанный на конкретный проект.
Выглядит как хорошая альтернатива десяткам каналов, разбросанных по всему коду
Но я решал немного другую задачу - goscade использует DAG (граф зависимостей) для строгого порядка выполнения. Зависимые компоненты ждут друг друга, а независимые части графа стартуют и останавливаются параллельно. Это нужно, чтобы при старте приложение гарантированно ждало подключения к базе, а при остановке не закрывало базу раньше, чем остановится веб-сервер. При этом два независимых Kafka-консьюмера стартуют одновременно
Рефлексия здесь - это трудный компромисс) Она используется только на этапе сборки графа на старте, чтобы автоматически определить зависимости между компонентами и убрать ручное связывание.
Я как раз и отталкивался от того, что «красиво остановить сильно сложнее, чем запустить», и что в реальных проектах это обычно вырастает в очень похожий код, размазанный по модулям.
Такой код часто не самый простой в отладке и сопровождении, поэтому хотелось собрать lifecycle в одном выделенном месте. Кроме того, при ручном управлении обычно приходится явно прокидывать зависимости между реализациями, что со временем увеличивает связанность.
Но если в конкретном проекте это удобно держать вручную - это действительно лучше, чем тянуть ещё одну библиотеку.
Рефлексия
Я использую ровно такой же подход в своих проектах - ручной контейнер, в котором компоненты обернуты в
LazyProvider.Но тут есть нюанс: передача зависимостей в конструктор - это уже достаточное условие для построения графа. (Если зависимость неявная, её можно задать в библиотеке руками).
Библиотека по сути просто автоматизирует работу с этим графом:
Граф перестраивается сам при изменении кода. Добавил аргумент в конструктор - порядок запуска обновился автоматически.
Библиотека сама определяет, какие независимые ветки запускать параллельно, а где нужно ждать.
"Из коробки" есть таймауты, аварийная остановка при ошибках и тд.
Если реализовывать весь этот функционал (параллельный старт, таймауты, графовое выключение) внутри своих методов инициализации вручную - ты по факту пишешь тот же goscade, только без рефлексии, но завязанный на конкретный проект.
Выглядит как хорошая альтернатива десяткам каналов, разбросанных по всему коду
Но я решал немного другую задачу - goscade использует DAG (граф зависимостей) для строгого порядка выполнения. Зависимые компоненты ждут друг друга, а независимые части графа стартуют и останавливаются параллельно. Это нужно, чтобы при старте приложение гарантированно ждало подключения к базе, а при остановке не закрывало базу раньше, чем остановится веб-сервер. При этом два независимых Kafka-консьюмера стартуют одновременно
Рефлексия здесь - это трудный компромисс) Она используется только на этапе сборки графа на старте, чтобы автоматически определить зависимости между компонентами и убрать ручное связывание.
Я как раз и отталкивался от того, что «красиво остановить сильно сложнее, чем запустить», и что в реальных проектах это обычно вырастает в очень похожий код, размазанный по модулям.
Такой код часто не самый простой в отладке и сопровождении, поэтому хотелось собрать lifecycle в одном выделенном месте. Кроме того, при ручном управлении обычно приходится явно прокидывать зависимости между реализациями, что со временем увеличивает связанность.
Но если в конкретном проекте это удобно держать вручную - это действительно лучше, чем тянуть ещё одну библиотеку.