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

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

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

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

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

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

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

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

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

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

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

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

https://github.com/jaypipes/ghw

FYI

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

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

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

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

трудно мысль уловить, но почитай закон Деметры, возможно ты про это

я решил на уровне main прокинуть в фабрику контейнер, а потом его там "растребушить" при инициализации

Looking at my current GraphQL API testing Go code I just had an idea of making GraphQL tests more declarative, because tests are what you want to be very easy to read and understand, error-prone testing is the worst! 1. define a query 2. define test conditions 3. define the expected parametric result 4. define expected conditions 5. implement the declared conditions in Go code 6. optionally, define the tests dependencies on other tests You'd generate the actual test code using gqltestgen ./, it'll collect all .gqltst files, parse them, generate a apitestsuite_test.go which can then be executed with go test -v -race This would also allow generating an API test coverage. The dependencies (test hierarchy) are useful to determine which tests should be run first to avoid having test query.user fail before mutation.createUser if actually the user creation mutation fails, not the user query node. What would you say? Do you like this idea? Do you think it's somehow limited or anything? Please don't hesitate to share your thoughts with me :leichtes_lächeln:

я решил на уровне main прокинуть в фабрику контейнер, а потом его там "растребушить" при инициализации

да, норм

извиняюсь за английский, но переписывать на русский лень)

да, норм

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

по хорошему он бы тоже мог контейнер дальше переслать...

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

компонент зависит от трех других компонентов. где тут место контейнеру? получил из контейнера три компонента и все

у меня есть webserver

самому ему зависимости не нужны никакие

но хедлерам его нужны

поэтому он получает экземляр контейнера и без "требушения" кидает в хенделы

можно сделать по другому, выдрать инициализацию хендлеров "наверх" и там их иницилизировать

и скормить ему же уже накормленные

поэтому тут два варианта

Да вроде все в main инициализировать нужно

Первый: serv := http.NewWebServer(app) serv.Lisner() // Для main не существует больше никаких суб зависимостей, они спрятаны внутри

второй

routes := handlers.NewRouters(app) // Мы вытащили зависимость наверх serv := http.NewWebServer(app) serv.Lisner(routes)

в принципе мне кажется что второй вариант правильней

но он несколько более многословный, что и смущает

ну вот я делаю пакет container, который состоит только из геттеров/фабрик. таким образом вся инициализация в одном месте. В остальном коде я только получаю готовые инстансы.

древнее зло пробудилось

коллеги, а есть ли у кого-нибудь проект в открытом доступе на swagger, в котором можно подглядеть как правильно разбивать спеку на несколько файлов?

+1

А кто какие библиотеки использует для работы с Docker API и как вы их мокаете? С Go работаю недавна, и вот встала передо мной такая задача

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

O_o

Я вот так хочу

- bin - user -- model.go // package user - cmd -- appname ---- main.go // package main - shared -- libname ---- any.go // package libname ---- test.go -- libnameTwo ---- any.go // package libnameTwo ---- test.go - vendor -- github.com ---- .... что-то такое "user" это домен, сам себе режиссер без зависимостей если их много, то можно положить в entities

Только у меня есть ещё папка db, и хочется там все запросы оставить к базе.

ну

Кажется нашёл статью, https://habr.com/post/269893/

в чем трабла то?

ну

Вот в чём, это образец: func main() { var p db.Handler db, err := p.InitDB() if err != nil { log.Fatal(err) } router := fasthttprouter.New() router.POST("/", db.getHandler) go func() { log.Fatal(fasthttp.ListenAndServe(":4000", router.Handler)) }() } func (p *Handler) getHandler(ctx *fasthttp.RequestCtx) { ... } getHandler отработает только если будет лежать в папке db. Но хэндлеры как-то не красиво там обрабатывать? Есть варианты?

Здравствуйте хотел бы задать вопрос, какую ORM лучше использовать? Пробовал gorm, но криво создаются связи, думаю перейти на go-pg, стоит ли? Слышал ещё про reform)