Looking for advice re; iodomatic inversion of control and dependency injection

<p>Hey folks,</p> <p>I&#39;m writing a nontrivial webapp in go (mostly net/http with some gorilla). This is my first time working with the language on a large scale project. I&#39;m curious what everyone&#39;s thoughts are regarding IoC and DI best practices in Go. I&#39;d like this project to be high-quality.</p> <p>I found these blog posts:</p> <p><a href="http://blog.parse.com/learn/engineering/dependency-injection-with-go/">Blog 1</a>: If I&#39;m understanding their method correctly, they have library which descends through a struct recursively and assigns instances to each field according to the field&#39;s tag (and shares the instances when appropriate). This is based on the <a href="https://github.com/facebookgo/inject">https://github.com/facebookgo/inject</a> library.</p> <p><a href="http://www.captaincodeman.com/2015/03/05/dependency-injection-in-go-golang/">Blog 2</a>: This guy recommends using build tags and interfaces to swap out components based on build context.</p> <p><a href="http://relistan.com/writing-testable-apps-in-go/">Blog 3</a>: This guy recommends wrapping pretty much everything you can in interfaces (including standard library objects), but doesn&#39;t really go into the actual injection part.</p> <p>As a brief footnote, I agonize choosing design patterns and best practices for my projects. I&#39;ve a hard time making a decision when most of the options are reasonable. Maybe it&#39;s because young. Some of my coworkers, on the other hand, seem willing to fight people to the death over these decisions.</p> <hr/>**评论：**<br/><br/>printf_hello_world: <pre><p>I recently recommended <a href="http://manuel.kiessling.net/2012/09/28/applying-the-clean-architecture-to-go-applications/" rel="nofollow">this</a> article to someone on a similar <a href="https://www.reddit.com/r/golang/comments/3awbyl/dependency_injection_by_overriding_interfaces/" rel="nofollow">thread</a>.</p> <p>Your article titles look pretty legit tho; I&#39;ll have to give them a read.</p></pre>40_is_too_many: <pre><p>Good call. I guess I oughta do a subreddit search before posting next time and not expect Google alone to surface all of the interesting threads. </p></pre>printf_hello_world: <pre><p>Alas, Google is not yet all-powerful.</p> <p>Btw, that thread is only 8 days old; some people may still appreciate your links there.</p></pre>drvd: <pre><p>I doubt that most Gophers would consider any form of DI or IOC idiomatic.</p></pre>klaaax: <pre><p>you can have 3 solutions: </p> <ul> <li>type injection.</li> </ul> <p>you can have a map that has as keys reflect.Type and as a value something to inject. then write your own logic to resolve dependencies.</p> <p>Which means you&#39;ll have to discriminate 2 objects with the same types with type conversion or with embedding</p> <pre><code> type Foo struct{} type Foo2 struct{Foo} </code></pre> <p>look at how Martini works, it is exactly that.</p> <ul> <li>repository with factories</li> </ul> <p>you can have a repository made of factories , values are resolved by name, once then cached through factories</p> <pre><code>injector.Register(&#34;foo2&#34;,func(i injector)interface{}{return Foo2{injector.MustResolve(&#34;foo&#34;).(Foo)} }) foo2,err := injector.Resolve(&#34;foo2&#34;).(Foo2) </code></pre> <p>can fail at runtime but you are supposed to write tests</p> <ul> <li>code generation</li> </ul> <p>Write a generator that will generate a struct + methods from a manifest where you define your dependencies. It&#39;s compile time safe.</p></pre>