а хедлеры в тестах значит работают без DI и кормяться вручную

может быть вы имеете введу что в DI должен "рефлектом" смотреть за зависимостями и подцеплять их?

нет

уже есть какие-нибудь фреймворки кодогенераторы декларативных API тестов?

ну я просто знаю как в PHP сделан DI, все классы которым требуются зависимости дергаются через оберточку аля DI("/namespace/className") дальше уже движок разбирает что там в конструкторе за зависимости и пытается их накормить (если есть)

есть идея как реализовать декларативные тесты GraphQL апишек, определяешь: 1. query 2. ожидаемый JSON 3. conditions (макро-функции, реализуются в Go коде)

Коллеги, панику из горутины никак не отловить?

Коллеги, панику из горутины никак не отловить?

defer func() { f := recover() }()

https://play.golang.org/p/N6NGMFH86g2

https://play.golang.org/p/N6NGMFH86g2

не выйдет, вы стартуете новый поток

в нем и отлавливайте

Т е автоматически никак.

Т е автоматически никак.

https://play.golang.org/p/07uP2U2Z1Kd

ну я просто знаю как в PHP сделан DI, все классы которым требуются зависимости дергаются через оберточку аля DI("/namespace/className") дальше уже движок разбирает что там в конструкторе за зависимости и пытается их накормить (если есть)

ты наверное забыл, но мы с этого разговора начали, когда ты появился в гошном чате. Нет, в пхп не так сделано. Ты рассказываешь какую-то определенную реализация ресолва зависимостей внутри контейнера. Конечно же не все контейнеры работают не рефлекте.

ну окей

в гоу то как принято с DI?

в го не принято di, сам знаешь

https://play.golang.org/p/07uP2U2Z1Kd

Это означает что в контексте горутины нужно отлавливать и по другому никак?

Это означает что в контексте горутины нужно отлавливать и по другому никак?

только так

Ок, спасибо

в го не принято di, сам знаешь

когда я описывал свою с вашего позволения "архитектуру" никто даже не пикнул ?

наоборот все говорили "ну зависимости надо статически отдавать и ок"

в смысле методов наделать аля GetDB()

когда я описывал свою с вашего позволения "архитектуру" никто даже не пикнул ?

у тебя память плохая)

в смысле методов наделать аля GetDB()

а в чем проблема? GetDb норм

и где его простите применять?

если я не могу контейнер с ним скоримть в хедлер

и где его простите применять?

если это метод контейнера

в данном случаи этот контейнер в структуре MyApplication

postStore := NewPostStore(container.GetDb()) userStore := NewUserStore(container.GetDb())

и зачем это?

я с такми же успехом могу написать

а не postStore := NewPostStore(container) userStore := NewUserStore(container)

db := db.NewConnect() ostStore := NewPostStore(db) userStore := NewUserStore(db)

почему тогда сразу не так?

только сущность наплодили "лишную"

и зачем это?

чтобы тестировать зависимости, а не зависимости зависимостей. Зачем твой компонент будет зависеть от чужих зависимостей, если должен зависеть от своих?

db := db.NewConnect() ostStore := NewPostStore(db) userStore := NewUserStore(db)

можно так. ты же просто переименовал метод

нихрена

если он не создает новый коннект кажддый раз, то это норм

создает

ну а зачем?

мы же в main и это уже вызов идет бд непосрдественно

так что сказать то хочешь?

я просто не вижу смысла тогда от "контейнера"

в твоей реализации

если мы из него дергаем обьект и передаем

какой смысл в контейнере?

сразу создаем на месте обьект и передаем уже

ну только инициализацию если спрятатать

погоди, если ты хочешь прямо в main все создать - создавай

блин я просто упроситил модель

конечно же нет

я тебе не контейнер показываю, а какие зависимости передавать

еще раз, если мы берем коннект бд из контейнера и передаем, зачем нам контейнер? Кроме помощи в инициализации бд

он откинулся до того как мы зашли в функцию

https://github.com/jaypipes/ghw

FYI

ERROR: S client not available

еще раз, если мы берем коннект бд из контейнера и передаем, зачем нам контейнер? Кроме помощи в инициализации бд

незачем. но можно контейнер в фабрику передавать. и в фабрике уже вытаскивать зависимости. Плюс в контейнере можно спрятать всю инициализацию. В общем конntйнер - это единый ресолвер зависимостей.

незачем. но можно контейнер в фабрику передавать. и в фабрике уже вытаскивать зависимости. Плюс в контейнере можно спрятать всю инициализацию. В общем конntйнер - это единый ресолвер зависимостей.

у меня был такой вариант

ключевое слово - ресолвер.

что есть "резолвер"?

type MyApplication struct { db *db.Database } func (app *MyApplication) GetDB() *db.Database { return app.db }

резолвер?

нет, просто контейнер

ты ушел от первоначальной проблемы

инъекция контейнера vs инъекция зависимостей

ну мы определили что я сделал не правильно

передал контейнер в хедлер

Всем привет. А подскажите - в defer функции параметры расчитываются в момент появления defer в коде (а не в момент завершения функции). С коллером будет также? Пример: func (o *obj) foo() { defer o.newTimer().stop() //other_code } newTimer() - вызовется в самом начале функции, а stop() будет вызван в конце?

да

Спасибо

инъекция контейнера vs инъекция зависимостей

ну ок. спасибо я ушел думать ?

ээм

а это к чему?

а это к чему?

к GraphQL

к GraphQL

у меня тут еще дополнительный вопрос, а как насчет каскадных зависимостей? Когда приложение кормиться в вебсервер, а вебсервер передает дальше в хедлеры (и оборачивает их)

или же надо делать "все на 1 уровне"

теоретически я мог бы хедлеры просто иницилизировать на уровне вебсервера и просто ему их скормить

не совсем понял

Вариант 1: serv := http.NewWebServer(app) serv.Lisner() // Внутри вызывается route который вызывает handlers Вариант 2: routes := handlers.NewRouters(app) serv := http.NewWebServer(app) serv.Lisner(routes)

стоит ли там "оборачивать"

или зависимости должны иди прозрачно без каскадов

ну ты главное компонент к контейнеру не привязывай, а так делай как хочешь

в ООП это как бы норм, глубина бывает по 7 элементов

я вижу что ты в фабрику контейнер прокидываешь. это не про зависимости