Dependency Injection with Go
blog.parse.com
Dependency Injection with Go
1–10 of 26 posts
Re: Dependency Injection with Go
#2Does anyone think this is a little stoppy (there isn't a Go equivalent to "unpythonic")?
Re: Dependency Injection with Go
#3"Typically the main() function would call the various init functions like InitMongoService"
Why muddy your main() when init() exists?
Re: Dependency Injection with Go
#4Does anyone think this is a little stoppy (there isn't a Go equivalent to "unpythonic")?
> there isn't a Go equivalent to "unpythonic"
Of course there is. :) Python does good marketing and rephrased an existing word, but the pair you're looking for is:
idiomatic / unidiomatic
Re: Dependency Injection with Go
#5Does anyone think this is a little stoppy (there isn't a Go equivalent to "unpythonic")?
Found it interesting that inject wires up the object graph and runs only once on application startup.
Curious to know your thoughts around why this lib could be considered non-idiomatic
Re: Dependency Injection with Go
#6Went down this path already.
It was OK for a while with a small codebase, but the problem is that you need to give up your simple direct Go code for magic reflection.
I discovered there are better and more idiomatic ways to do this type if thing without resorting to dependency injection.
Re: Dependency Injection with Go
#7Went down this path already. It was OK for a while with a small codebase, but the problem is that you need to give up your simple direct Go code for magic reflection. I discovered there are better and more idiomatic ways to do this type if thing without resorting to dependency injection.
Strongly agree. A verbose `main` carries the benefit of being explicit and unambiguous. Components whose constructors take all of their dependencies are simple to reason about and straightforward to test.
The code described in the article seems like it's burdened with patterns from other languages and ecosystems, and which are pretty nonidiomatic Go: "AppLoader"? The complexity of their final solution seems to be a result of not challenging those patterns and assumptions.
Re: Dependency Injection with Go
#8"Typically the main() function would call the various init functions like InitMongoService" Why muddy your main() when init() exists? See: http://golang.org/ref/spec#Package_initialization
And why use InitXxx at all, when you can create an initialized, locally-scoped MongoService with a constructor, and pass it to the things that need it?
Re: Dependency Injection with Go
#9"Typically the main() function would call the various init functions like InitMongoService" Why muddy your main() when init() exists? See: http://golang.org/ref/spec#Package_initialization
And why use InitXxx at all, when you can create an initialized, locally-scoped MongoService with a constructor, and pass it to the things that need it?
I was referring to Go's magic func init()
Putting that in your files, let's say:
db.go func init() => handle global DB's...
templates.go func init() => handle HTML templates...
settings.go func init() => load some settings...
Re: Dependency Injection with Go
#10Went down this path already. It was OK for a while with a small codebase, but the problem is that you need to give up your simple direct Go code for magic reflection. I discovered there are better and more idiomatic ways to do this type if thing without resorting to dependency injection.
> I discovered there are better and more idiomatic ways to do this type if thing without resorting to dependency injection.
Agreed. Write a constructor[1] for your "app" or "context" type, and pass it around as needed. You both get to avoid globals and any magic dependency injection.
As a bit of shameless self-promotion, I wrote an article about how to achieve this when writing HTTP handlers in Go: http://elithrar.github.io/article/custom-handlers-avoiding-g... - hint: create a struct type that accepts a pointer to your app struct and your handler type/http.Handler, or create your handlers as methods on your app type.