Dependency Injection in Composition Root: Pros and Cons

Your binding module approach is the best solution. If the client is unlikely to change the configuration, the use of DI is questionable, for your library specifically.

If you wish to create a library for release to the public, you probably don't want clients to deal with the complexity or rigidity of the particular DI system you favor at the moment. Libraries are best when they are lower level components that can be used without lots of dependencies, or extensive training. Any DI system you select will change over time, and may become incompatible with client applications.

Consider these classes, and their dependencies explicitly listed as argumetns to the constructor.

class SomeClass {
    public SomeClass(IFoo foo, IBar bar) {}
}

class Foo : IFoo {
    public Foo(IBaz baz) {}
}

class Bar : IBar {}

class Baz :IBaz {}

The Graph would look like this:

• SomeClass
  • IFoo
    • IBaz
  • IBar

Now, assembling this by Hand means creating instances the whole object graph, with its dependencies:

var baz = new Baz();
var foo = new Foo(baz);
var bar = new Bar();
var someClass = new SomeClass(foo, bar);

Using an IOC container with constructor injection is not really different. The thing you have to grasp is: You pull on one end, and the graph will follow:

container.add(IFoo, Foo);
container.add(IBar, Bar);
container.add(IBaz, Baz);
container.add(ISomeClass, SomeClass);

// now pull on your "Entry Point"/"Bootstrap":
container.get(ISomeClass);

The container will resolve and inject dependencies as needed. You do not have to resolve anything by hand, with one exception: This is your entry point.