A typical enterprise application does not consist of one single object (or bean in Spring terminology). Even in the simplest application, there are multiple objects that work together to create what the end user sees as a cohesive, cohesive application. The following explains how to move from defining a few stand-alone bean definitions to a fully realized application in which objects interact with each other to produce a result.

Dependency injection (DI) is the process by which objects define their dependencies (that is, other objects they operate on) solely through constructor arguments, factory method arguments, or properties that are set to an instance of the object after it is created or returned from the factory method. The container then injects these dependencies when the bean is created. This process is essentially an inversion (hence the name, Inversion of Control) of the bean itself, which independently controls the creation or placement of its dependencies using direct construction of classes or a Service Locator pattern.

The code becomes cleaner thanks to the DI principle, and separation is more efficient if objects are assigned their own dependencies. The object does not look up its dependencies and does not know the location or class of the dependencies. As a result, classes become easier to test, especially if dependencies are on interfaces or abstract base classes, allowing implementations of a stub function or mock object to be used in unit tests.

DI comes in two main flavors: Constructor-based dependency injection and setter-based dependency injection.