D
ну это уже вопрос архитектуры, зачем вам такой способ вызывать сервис
Size: a a a
2021 May 20
D
голанг к колбек хелу не распологает, это не жс
FL
DI - просто про прием типов на уровне сигнатуры/типа проперти и т.п
А я спрашиваю насчет того, как лучше прокидывать типы. Напрямую в функцию, а сама функция уже пусть запоминает в проперти структуры/еще как-нибудь
ioc container на рефлексии
глобальные переменные наше все
и т.п
А я спрашиваю насчет того, как лучше прокидывать типы. Напрямую в функцию, а сама функция уже пусть запоминает в проперти структуры/еще как-нибудь
ioc container на рефлексии
глобальные переменные наше все
и т.п
FL
Условно, в шарпе я возьму ioc container и буду просто использовать его.
То, что он глобальный - ну ок, фиг с ним. Зато кроме него больше ничего (в явном виде)
Где мне нужно, в сигнатуру прокину типы и пусть контейнер мне резолвит это. Или напрямую достану.
Юзабелен ли такой подход в го...
То, что он глобальный - ну ок, фиг с ним. Зато кроме него больше ничего (в явном виде)
Где мне нужно, в сигнатуру прокину типы и пусть контейнер мне резолвит это. Или напрямую достану.
Юзабелен ли такой подход в го...
D
такой подход нигде не юзабелен
FL
Как это не юзабелен?)
D
если вы его используете в шарпе, то это зря
FL
Возможно мы о разных вещах?
D
может быть, я про глобальный контейнер откуда можно взять любую зависимость
D
вместо того чтобы прокинуть нужные зависимости вы прокидываете только контейнер ?
FL
Все верно, это ioc container. Я тоже о нем
FL
Нет, контейнер сам все резолвит
D
таким образом он делает DI
D
либо я не понимаю о чем вы, дайте пример на шарпе
C
у нас так не принято
C
есть гугловый Wire
C
Но это специфичная хрень которая скорее всего вам не нужна
FL
> У нас
Я знаю что в го не используют такой подход, но что-то кроме глобальных переменных должно ж быть
Я знаю что в го не используют такой подход, но что-то кроме глобальных переменных должно ж быть
C
Прокидывание зависимостей руками