A reflection based dependency injection toolkit for Go.

Overview

⚒️ dig GoDoc GitHub release Build Status Coverage Status Go Report Card

A reflection based dependency injection toolkit for Go.

Good for:

  • Powering an application framework, e.g. Fx.
  • Resolving the object graph during process startup.

Bad for:

  • Using in place of an application framework, e.g. Fx.
  • Resolving dependencies after the process has already started.
  • Exposing to user-land code as a Service Locator.

Installation

We recommend consuming SemVer major version 1 using your dependency manager of choice.

$ glide get 'go.uber.org/dig#^1'
$ dep ensure -add "go.uber.org/[email protected]"
$ go get 'go.uber.org/[email protected]'

Stability

This library is v1 and follows SemVer strictly.

No breaking changes will be made to exported APIs before v2.0.0.

Issues
  • Allow to specify an interface when providing a constructor

    Allow to specify an interface when providing a constructor

    Update (by @glibsm)

    The addition of dig.As ProvideOption has been agreed on.


    Currently dig only uses a constructors that returns exactly what the function expects.

    If the function accepts an interface, and we don't inject the constructor that returns that interface we get this error

    panic: missing dependencies for function "main".main.func1 (..../main.go:29): type main.Fooer is not in the container, did you mean to use *main.Foo?
    

    Take the following example

    type Foo struct{}
    
    func NewFoo() *Foo {
    	return &Foo{}
    }
    
    func (b *Foo) Hello() {
    	fmt.Println("hello")
    }
    
    type Fooer interface {
    	Hello()
    }
    
    func main() {
    	di := dig.New()
    	err := di.Provide(NewFoo)
    	if err != nil {
    		panic(err)
    	}
    	err = di.Invoke(func(f Fooer) {
    		fmt.Printf("f: %+v", f)
    	})
    	if err != nil {
    		panic(err)
    	}
    }
    

    So to make it work it needs to have a constructor function such as:

    func NewFoo() Fooer {
    	return &Foo{}
    }
    

    ~which is basically making us declare that Foo implements Fooer~ ~Would it be feasible to change the library so that it can workout itself if the struct implements the interface?~ [edit] as clarified in the comments this suggestion won't work

    Or alternatively, add a new ProvideOption which allow us to specify which concrete implementation to inject for a given interface?

    opened by alessandrozucca 25
  • Prevent wasteful recursion by tracking param visits in detectCycles

    Prevent wasteful recursion by tracking param visits in detectCycles

    This is an iteration on #207

    opened by dnathe4th 24
  • Does not work with go.mod / vgo

    Does not work with go.mod / vgo

    Just import go.uber.org/dig to any go.mod enabled project and then run vgo mod -sync

    import "go.uber.org/dig" ->
    import "go.uber.org/dig/internal/digreflect" ->
    test ->
    import "go.uber.org/dig/internal/digreflect/tests/myrepository.git" ->
    import "mydependency": cannot find module providing package mydependency
    
    opened by albenik 23
  • Allow

    Allow "fan-in" for named types in dig graph

    I've been talking to @abhinav about this, In order to support use cases where a dig parameter depends on multiple inputs of the same type we need the ability to aggregate dig types together.

    So if we have the following outputs:

      Output1 MyType `name:"output1"`
      Output2 MyType `name:"output2"`
    

    I'd want to be able to grab all the "MyType"s in a single attribute.

    Solutions

    1: Add another tag to indicate that the type should be a fan-in collection:

    type In struct {
      dig.In
      Outputs map[string]MyType `collection:"true"` // tag name TBD
    }
    

    The string key in the Outputs variable will be the name of the attributes that were injected into the graph.

    2: Add a dig.Key (or similar) type for map keys. Any map of these types will be recognized as a fan-in collection.

    type In struct {
      dig.In
      Outputs map[dig.Key]MyType
    }
    

    The dig.Key would be a dig struct where we could embed information on the type. Currently that would only be the "name", but we could add more information later.

    Use cases

    YARPC Middleware

    Currently we don't have a good answer for middleware to ensure that we can take multiple middleware inputs and effectively construct a middleware graph without forcing the yarpcfx module to have a hard dependency on every middleware library (which gets out of control). With this system we'd be able to grab all middleware that was inserted into the graph. Since this is a map, the yarpcfx module would need to have an ordered list of middleware names it was expecting beforehand (all names should be optional) and it can construct the middleware chain itself. Of course this would only support names that yarpcfx explicitly expects, but that is necessary for the middleware ordering.

    YARPC Specs:

    The yarpc config options allow inserting custom Transport/PeerList/Updater specs into the yarpc config builder. Having support for this would allow us to detach the yarpc fx module from the implementations of each transport. For instance, a user could inject a "grpcfx" module into the graph which provided a "TransportSpec" for grpc that integrated seamlessly into the yarpc configuration.

    opened by willhug 22
  • Add SkipAcyclicVerification Option, and container.VerifyAcyclic

    Add SkipAcyclicVerification Option, and container.VerifyAcyclic

    It is not unreasonable for libraries using dig under the hood for dependency graph management to c.Provide constructors in a tight loop. Rather than paying the cost of of verifying the graph is acyclic for every Provide, this option and method combination can be used to verify the graph once, after the loop has completed.

    opened by dnathe4th 18
  • dig.Param: Recurse into nested parameter objects

    dig.Param: Recurse into nested parameter objects

    This change adds support to parameter objects for recursing into fields that are also parameter objects. That is, this change allows the following,

    type OutputConfig struct {
        dig.Param
    
        Writer io.Writer
    }
    
    type Config struct {
        dig.Param
    
        Input io.Reader
        Output OutputConfig
    }
    
    func NewTransport(cfg Config) (*Transport, error) { .. }
    

    Besides the usefulness of treating fields similar to constructor parameters, there's another motivating use case for this: Aliasing dig.Param. Without this change, we have special handling for the dig.Param type, opting it out of resolution from dig. If a library author wants to use their own type in place of dig.Param (for example, fx.Param), they can't quite do this because any alias of dig.Param is a different type; one which the library does not special-case.

    package fx
    
    type Param dig.Param
    
    type Config struct {
        Param
    
        Input io.Reader
    }
    
    // The above with fail because dig doesn't know how to resolve fx.Param.
    

    With this change, Fx will be able to support the following.

    package fx
    
    type Param struct{ dig.Param }
    
    type Config struct {
        Param
    
        // ..
    }
    
    opened by abhinav 14
  • Add dig.Optional for marking optional params

    Add dig.Optional for marking optional params

    Realized that fx can be improved so certain parameters provided, while in their absence, a default parameter value would be used.

    Add a new dig.Optional type that can be embedded in structs to mark that the dependency on them is optional.

    opened by orishu 13
  • [Prototype] Zero-value validation approach

    [Prototype] Zero-value validation approach

    Currently dig returns an error dependency of type is not registered if constructor argument fails to resolve during Invoke or Resolve. This change is introduced to resolve any absent arguments with zero value objects. Zero value objects are resolved during resolving constructor or invoking a function with arguments not yet present in the DIG container.

    When can it happen?

    1. Constructors are provided out of order
    2. Optional objects are not provided to the constructor

    What will be the expected behavior?

    1. No change in existing API on the container
    2. Invoke, resolving constructor never fails on missing constructor arguments in DIG container.
    3. Constructor is provided with zero value argument during call to continue execution
    4. Invoke/Resolve logs error message when zero value object is used
    5. Zero value object is never cached.
    discussion 
    opened by anuptalwalkar 12
  • Invoke on provided/unprovided ctors

    Invoke on provided/unprovided ctors

    Calling Invoke on provided and unprovided funcs can result in executing constructors more than once and overwriting the graph with the resulted return objects. for provided constructors -

    ctor1(a *A, b *B) (x *x)
    ctor2() (a *A)
    

    Invoking constructors in order will result in ctor1 resolving *A and *B. Invoking ctor2 will result in resolving *A again.

    enhancement discussion 
    opened by anuptalwalkar 12
  •  Combine Resolve, ResolveAll, and Invoke into a Locate func

    Combine Resolve, ResolveAll, and Invoke into a Locate func

    When you ask the container to resolve dependencies, that is called the "service locator" pattern.

    Combining Resolve, ResolveAll, and Invoke into a Locate func will streamline the experience:

    // locate 1 or more types
    var logger *zap.Logger
    var dispatcher *yarpc.Dispatcher
    container.Locate(&logger, &dispatcher)
    
    // same as above, using a func
    container.Locate(func(logger *zap.Logger, dispatcher *yarpc.Dispatcher) {
     
    })
    

    This has the benefit of:

    • Being more specific, giving a nod to the pattern actually being used here
    • Reduces API surface and simplifies using DIG
    opened by GoodPete 12
  • Refactor graph representation

    Refactor graph representation

    This is the first PR to prepare Dig for in-graph modifications.

    This PR contains several changes to allow further extensibility in the graph representation used in Dig, and decouple reflection Type info from the graph algorithms as much as possible.

    Specifically, this PR makes the following changes:

    • Add internal/graph package which contains Dig-agnostic graph algorithm used for cycle detection
    • Remove the somewhat duplicated embedded cycle detection logic in Container and cycle.go
    • Add graphHolder type in Container which holds all the graph nodes and implements the graph iterator interface used for graph algorithm in internal/graph.
    • Add paramGroupedSlice as part of node in graph.
    • Remove the param visitor funcs and related helpers.
    • Rename node to constructorNode.

    There is also a change in the way cycle error messages are displayed. Previously, the errors looked like:

    typeA provided by funcName (file_location.go:line_number)
      depends on typeB provided by funcName (file_location.go:line_number)
      depends on typeC provided by funcName (file_location.go:line_number)
     ... and so on
    

    This error message generation depended on knowing the "edge" info between nodes, which is the reflect.Type that connects the two constructor nodes.

    Now that the graph representation holds not only constructor nodes but also value groups, and because graph representation does not know what type holds the nodes together, this needs to be changed.

    Now, the error messages look like:

    func(*typeB) *typeA provided by funcName(file_location.go:line_number)
      depends on func(*typeC) *typeB provided by funcName(file_location.go:line_number)
      depends on func(*typeA) *typeC provided by funcName(file_location.go:line_number)
    ... and so on
    

    (Note that the function signature is now printed instead of the type that holds the nodes as dependencies).

    For param value groups, the error message skips over it so that the error message doesn't look cluttered but that can be subject to change in the future.

    opened by sywhang 3
  • add InvokeOption and ProvideOption for Names

    add InvokeOption and ProvideOption for Names

    Addresses #181

    Allows a constructor or invoke to specify the names of dependencies.

    opened by tylersouthwick 1
  • Declaring Provider/Injector using Comment?

    Declaring Provider/Injector using Comment?

    Hi, I'm considering using comment to declare provider/injector while it's boring to pass provider/injector to dig container:

    c := dig.New()
    err = c.Provide(NewFoo)
    if err != nil {
        return errors.WithMessage(err, "provide NewFoo failed")
    }
    

    Using comment,we could write code like this:

    //go:generate diggen
    
    // dig:provider
    func NewFoo() Foo {
        return Foo{}
    }
    
    // dig:invoke
    func InitFoo(foo Foo) {
        // do something with foo
    }
    

    Then some tools can generate code from comment.

    func Inject(c *dig.Container) error {
        ver err error
        err = c.Provide(NewFoo)
        if err != nil {
            return errors.WithMessage(err, "provide NewFoo failed")
        }
        return nil
    }
    
    func Invoke(c *dig.Container) error {
        var err error
        err = c.Invoke(InitFoo)
            if err != nil {
            return errors.WithMessage(err, "invoke InitFoo failed")
        }
        return nil
    }
    

    Is this a good way?

    opened by zsh1995 1
  • Add support to invoke a function between multiple containers

    Add support to invoke a function between multiple containers

    This implementation allows developers to invoke specific function between multiple containers. This may be useful in case of you have a container instantiated at application startup (singleton container) and a second container instantiated just before handle every HTTP request (factory container).

    With GroupInvoke you can resolve dependencies across singleton and factory container.

    opened by RobyFerro 3
  • Add a way to produce information on Invokes

    Add a way to produce information on Invokes

    See https://github.com/uber-go/dig/pull/280#issuecomment-866125173

    #280 adds a way for users to gain info on Provided constructors.

    It'd be nice to expose a similar method to gain info on Invoked functions.

    Refs GO-669.

    opened by sywhang 0
  • where is the quick start and docs?

    where is the quick start and docs?

    opened by qq1778551951 1
  • Dependency cycle not detected when using `DeferAcyclicVerification()` (default in `fx.new()`)

    Dependency cycle not detected when using `DeferAcyclicVerification()` (default in `fx.new()`)

    This is not a fix, just an "annotated issue". I don't have the time nor the insight behind the design of https://github.com/uber-go/dig/pull/209 to bring this home. Hope this is helpful but feel free to close if it isn't.

    opened by schomatis 1
  • Unconstructable optional types provided to the container should not silently fail

    Unconstructable optional types provided to the container should not silently fail

    Take the following minimal example:

    package main
    
    import (
    	"fmt"
    	"go.uber.org/dig"
    )
    
    type A struct {
    	b *B
    	c *C
    }
    type B struct{}
    type C struct{}
    type D struct{}
    
    type paramsA struct {
    	dig.In
    
    	B *B
    	C *C `optional:"true"`
    }
    
    func main() {
    	c := dig.New()
    
    	c.Provide(func(p paramsA) *A {
    		return &A{
    			b: p.B,
    			c: p.C,
    		}
    	})
    	c.Provide(func() *B { return &B{} })
    	c.Provide(func(d *D) *C { return &C{} })
    
    	if err := c.Invoke(func(a *A) {
    		fmt.Printf("a.c == nil is %t \n", a.c == nil)
    	}); err != nil {
    		panic(err)
    	}
    }
    

    Running this will return the string "a.c == nil is true". Despite the fact that a constructor was Provided to the container for *C, there is no feedback to the user that a.c == nil because *C's dependencies were not fulfilled. The only way to arrive at this conclusion without tracing back every optional dependency to all of their dependencies is to remove the optional:"true" tag temporarily and see what error dig returns when the container is resolved.

    Instead, I contend that when an optional dependency does have a constructor Provided to the container, either (1) an error should always be returned if the optional dependency's dependencies cannot be met, or (2) a flag should able to be provided to the container (maybe some "strict" mode?) for cause optional dependency errors to be returned for easy debuggability.

    opened by dnathe4th 3
  • Features: As & Replace

    Features: As & Replace

    Guys, you library are really good. We are using it in our production microservices. But it was a long time ago when you issued major version.

    In real life we need some features, that already implemented, but not issued in major version (dig.As) and some features, that not implemented at all (like runtime Replace interface definition - we need it in testing purposes).

    Many new libraries was issued since you last update, that already has this features. For example https://github.com/defval/inject

    It would be great if you'll issue major version finally and include features listed above in this version.

    Cheers!

    opened by splokhikh 0
  • [WIP] Sub graphs and Decorate

    [WIP] Sub graphs and Decorate

    uber-go/fx#653

    Also address #230

    Added support for creating child containers.

    • [x] Containers have access to all types provided using their parents (Invoke works anywhere)
    • [x] Containers have access to all types provided using their children (Invoke works anywhere)
    • [x] Provide checks the entire graph (all containers both up and down) for duplicates
    • [x] All success tests repeated for children
    • [x] Tests for multiple and multi level children
    • [x] Test for duplicate check in one of the children
    • [x] Stringer updated
    opened by srikrsna 16
Releases(v1.13.0)
  • v1.13.0(Sep 21, 2021)

    Added

    • Introduce As option which supports providing a type as interface(s) it implements to the container.
    • Add LocationForPC option which overrides the function inspection for a program counter address to a provided function info.
    Source code(tar.gz)
    Source code(zip)
  • v1.12.0(Aug 4, 2021)

    Added

    • Support for ProvideInfo and FillProvideInfo that allow the caller of Provide to get info about what dig understood from the constructor.
    Source code(tar.gz)
    Source code(zip)
  • v1.11.0(Jun 9, 2021)

  • v1.10.0(Jun 16, 2020)

    Added

    • Introduce DryRun Option which, when set to true, disables invocation of functions supplied to Provide and Invoke. This option will be used to build no-op containers, for example for fx.ValidateApp method.
    Source code(tar.gz)
    Source code(zip)
  • v1.9.0(Apr 6, 2020)

    Added

    • GraphViz visualization of the graph now includes names of packages next to constructors.
    • Added a flatten modifier to group tags for slices to allow providing individual elements instead of the slice for a group value. See package doucmentation for more information.

    Changed

    • Drop library dependency on golang.org/x/lint.
    • Support printing multi-line error messages with %+v.
    Source code(tar.gz)
    Source code(zip)
  • v1.8.0(Nov 14, 2019)

  • v1.7.0(Jan 4, 2019)

    Added

    • Added Group option for Provide to add value groups to the container without rewriting constructors. See package doucmentation for more information.
    Source code(tar.gz)
    Source code(zip)
  • v1.6.0(Nov 6, 2018)

    Changed

    • When an error graph is visualized, the graph is pruned so that the graph only contains failure nodes.
    • Container visualization is now oriented from right to left.
    Source code(tar.gz)
    Source code(zip)
  • v1.5.1(Nov 1, 2018)

  • v1.5.0(Sep 19, 2018)

    Added

    • Added a DeferAcyclicVerification container option that defers graph cycle detection until the next Invoke.

    Changed

    • Improved cycle-detection performance by 50x in certain degenerative cases.
    Source code(tar.gz)
    Source code(zip)
  • v1.4.0(Aug 17, 2018)

    Added

    • Added Visualize function to visualize the state of the container in the GraphViz DOT format. This allows visualization of error types and the dependency relationships of types in the container.
    • Added CanVisualizeError function to determine if an error can be visualized in the graph.
    • Added Name option for Provide to add named values to the container without rewriting constructors. See package documentation for more information.

    Changed

    • name:"..." tags on nested Result Objects will now cause errors instead of being ignored.
    Source code(tar.gz)
    Source code(zip)
  • v1.3.0(Dec 4, 2017)

  • v1.2.0(Nov 7, 2017)

    • dig.In and dig.Out now support value groups, making it possible to produce many values of the same type from different constructors. See package documentation for more information.
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Sep 15, 2017)

    • Added the dig.RootCause function which allows retrieving the original constructor error that caused an Invoke failure.
    • Errors from Invoke now attempt to hint to the user a presence of a similar type, for example a pointer to the requested type and vice versa.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Jul 31, 2017)

    First stable release: no breaking changes will be made in the 1.x series.

    • Provide and Invoke will now fail if dig.In or dig.Out structs contain unexported fields. Previously these fields were ignored which often led to confusion.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-rc2(Jul 21, 2017)

    • Added variadic options to all public APIS so that new functionality can be introduced post v1.0.0 without introducing breaking changes.
    • Functions with variadic arguments can now be passed to dig.Provide and dig.Invoke. Previously this caused an error, whereas now the args will be ignored.
    • Exported dig.IsIn and dig.IsOut so that consuming libraries can check if a params or return struct embeds the dig.In and dig.Out types, respectively.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-rc1(Jun 21, 2017)

  • v0.5.0(Jun 19, 2017)

    • dig.In and dig.Out now support named instances, i.e.:

      type param struct {
        dig.In
      
        DB1 DB.Connection `name:"primary"`
        DB2 DB.Connection `name:"secondary"`
      }
      
    • Structs compatible with dig.In and dig.Out may now be generated using reflect.StructOf.

    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Jun 12, 2017)

    • [Breaking] Remove Must* funcs to greatly reduce API surface area.
    • [Breaking] Restrict the API surface to only Provide and Invoke.
    • Providing constructors with common returned types results in an error.
    • [Breaking] Update Provide method to accept variadic arguments.
    • Add dig.In embeddable type for advanced use-cases of specifying dependencies.
    • Add dig.Out embeddable type for advanced use-cases of constructors inserting types in the container.
    • Add support for optional parameters through optional:"true" tag on dig.In objects.
    • Add support for value types and many built-ins (maps, slices, channels).
    Source code(tar.gz)
    Source code(zip)
  • v0.3(May 2, 2017)

    API renaming and introducing Invoke functionality

    • Rename RegisterAll and MustRegisterAll to ProvideAll and MustProvideAll.
    • Add functionality to Provide to support constructor with n return objects to be resolved into the dig.Graph
    • Add Invoke function to invoke provided function and insert return objects into the dig.Graph
    Source code(tar.gz)
    Source code(zip)
  • v0.2(Mar 28, 2017)

    API cleanup and removal of the global graph

    • Rename Register to Provide for clarity and to reduce clash with other Register functions.
    • Rename dig.Graph to dig.Container.
    • Remove the package-level functions and the DefaultGraph.
    Source code(tar.gz)
    Source code(zip)
  • v0.1(Mar 23, 2017)

    This version is all about singleton objects: create them, share them in the graph through constructors, or by registering a pointer directly.

    Source code(tar.gz)
    Source code(zip)
Owner
Uber Go
Uber's open source software for Go development
Uber Go
An additive dependency injection container for Golang.

Alice Alice is an additive dependency injection container for Golang. Philosophy Design philosophy behind Alice: The application components should not

Minjie Zha 43 Sep 15, 2021
🛠 A full-featured dependency injection container for go programming language.

DI Dependency injection for Go programming language. Tutorial | Examples | Advanced features Dependency injection is one form of the broader technique

Goava 108 Nov 30, 2021
Go Dependency Injection Framework

Dingo Dependency injection for go Hello Dingo Dingo works very very similiar to Guice Basically one binds implementations/factories to interfaces, whi

Flamingo 115 Nov 24, 2021
Simple Dependency Injection Container

?? gocontainer gocontainer - Dependency Injection Container ?? ABOUT Contributors: Rafał Lorenz Want to contribute ? Feel free to send pull requests!

Rafał Lorenz 14 Dec 10, 2020
Simple and yet powerful Dependency Injection for Go

goioc/di: Dependency Injection Why DI in Go? Why IoC at all? I've been using Dependency Injection in Java for nearly 10 years via Spring Framework. I'

Go IoC 121 Nov 25, 2021
Dependency Injection and Inversion of Control package

Linker Linker is Dependency Injection and Inversion of Control package. It supports the following features: Components registry Automatic dependency i

Logrange 32 May 6, 2021
Strict Runtime Dependency Injection for Golang

wire Wire is runtime depedency injection/wiring for golang. It's designed to be strict to avoid your go application running without proper dependency

Muhammad Surya 34 Sep 28, 2021
Compile-time dependency injection for Go

Dihedral Dihedral is a compile-time injection framework for Go. Getting started > go get -u github.com/dimes/dihedral Create a type you want injected

null 76 Sep 4, 2020
Compile-time Dependency Injection for Go

Wire: Automated Initialization in Go Wire is a code generation tool that automates connecting components using dependency injection. Dependencies betw

Google 7k Dec 4, 2021
Generated dependency injection containers in go (golang)

Generation of dependency injection containers for go programs (golang). Dingo is a code generator. It generates dependency injection containers based

null 64 Nov 22, 2021
A dependency injection library that is focused on clean API and flexibility

Dependency injection DI is a dependency injection library that is focused on clean API and flexibility. DI has two types of top-level abstractions: Co

Sergey Treinis 3 Nov 2, 2021
Golang PE injection on windows

GoPEInjection Golang PE injection on windows See: https://malwareunicorn.org/workshops/peinjection.html Based on Cryptowall's PE injection technique.

malwareunicorn 137 Nov 24, 2021
two scripts written in golang that will help you recognize dependency confusion.

two scripts written in golang that will help you recognize dependency confusion.

gv1_ 5 Oct 4, 2021
A dependency injection based application framework for Go.

?? Fx An application framework for Go that: Makes dependency injection easy. Eliminates the need for global state and func init(). Installation We rec

Uber Go 2.4k Dec 5, 2021
🦄🌈 YoyoGo is a simple, light and fast , dependency injection based micro-service framework written in Go.

???? YoyoGo is a simple, light and fast , dependency injection based micro-service framework written in Go. Support Nacos ,Consoul ,Etcd ,Eureka ,kubernetes.

YoyoFx 495 Dec 3, 2021
How we can run unit tests in parallel mode with failpoint injection taking effect and without injection race

This is a simple demo to show how we can run unit tests in parallel mode with failpoint injection taking effect and without injection race. The basic

amyangfei 1 Oct 31, 2021
hiboot is a high performance web and cli application framework with dependency injection support

Hiboot - web/cli application framework About Hiboot is a cloud native web and cli application framework written in Go. Hiboot is not trying to reinven

hidevops.io 162 Nov 22, 2021
An additive dependency injection container for Golang.

Alice Alice is an additive dependency injection container for Golang. Philosophy Design philosophy behind Alice: The application components should not

Minjie Zha 43 Sep 15, 2021
🛠 A full-featured dependency injection container for go programming language.

DI Dependency injection for Go programming language. Tutorial | Examples | Advanced features Dependency injection is one form of the broader technique

Goava 108 Nov 30, 2021
Go Dependency Injection Framework

Dingo Dependency injection for go Hello Dingo Dingo works very very similiar to Guice Basically one binds implementations/factories to interfaces, whi

Flamingo 115 Nov 24, 2021
Simple Dependency Injection Container

?? gocontainer gocontainer - Dependency Injection Container ?? ABOUT Contributors: Rafał Lorenz Want to contribute ? Feel free to send pull requests!

Rafał Lorenz 14 Dec 10, 2020
Simple and yet powerful Dependency Injection for Go

goioc/di: Dependency Injection Why DI in Go? Why IoC at all? I've been using Dependency Injection in Java for nearly 10 years via Spring Framework. I'

Go IoC 121 Nov 25, 2021
Dependency Injection and Inversion of Control package

Linker Linker is Dependency Injection and Inversion of Control package. It supports the following features: Components registry Automatic dependency i

Logrange 32 May 6, 2021
Strict Runtime Dependency Injection for Golang

wire Wire is runtime depedency injection/wiring for golang. It's designed to be strict to avoid your go application running without proper dependency

Muhammad Surya 34 Sep 28, 2021
Minimalistic, pluggable Golang evloop/timer handler with dependency-injection

Anagent Minimalistic, pluggable Golang evloop/timer handler with dependency-injection - based on codegangsta/inject - go-macaron/inject and chuckpresl

Ettore Di Giacinto 13 Jun 22, 2021
Compile-time dependency injection for Go

Dihedral Dihedral is a compile-time injection framework for Go. Getting started > go get -u github.com/dimes/dihedral Create a type you want injected

null 76 Sep 4, 2020
Gerasimos (Makis) Maropoulos 21.5k Dec 1, 2021
Compile-time Dependency Injection for Go

Wire: Automated Initialization in Go Wire is a code generation tool that automates connecting components using dependency injection. Dependencies betw

Google 7k Dec 4, 2021
Generated dependency injection containers in go (golang)

Generation of dependency injection containers for go programs (golang). Dingo is a code generator. It generates dependency injection containers based

null 64 Nov 22, 2021