Comparison
AutowiringvsDependency injection container
Autowiring
nothing in the code says where the implementation came from, and the answer is that a scan found exactly one.
Letting a container work out which implementation satisfies a dependency, usually by scanning for types that fit. It removes a large amount of registration boilerplate and removes the ability to answer 'where does this come from' by reading. The characteristic failure is a second implementation appearing and the resolution becoming ambiguous — or worse, unambiguous and wrong.
Full entry →Dependency injection container
you registered an interface against a class once, and everything that needs it gets one without anybody passing it.
A library that holds the map from abstraction to implementation and constructs object graphs on demand, handling lifetimes and nested dependencies. It earns its place in an application with hundreds of components; below that it mostly replaces a readable composition root with a configuration you cannot step through. Its two recurring costs are resolution errors that surface at runtime rather than compile time, and lifetime mistakes the container will happily make for you.
Full entry →