Control inversion (IOC) and Dependency injection (DI)
The IOC is a broad concept: the control of something is transferred from a to B.
DI is an implementation of the IOC, implemented in a way that relies on x,b to give X to a in the way injected, without needing a to acquire or create X itself. In this case, the control of X is transferred from A to B here, which is the realization of the IOC.
Take a life example: the front desk receives your courier, and you write the code on the station. In general this time, I will stop the work in hand, to the front desk to bring back The courier. And for the use of dependency injection is the case, you will take control of the express delivery to the front desk, let her bring it to you, this time you are more convenient.
Another example of code-related (in order to simplify, no interface is used):
NewNew New Car (shell, wheel);
Car.run ();
What is needed, what to create, and finally assembled to use, the core business logic is a row of run, but write a lot of lines of assembly code (more complex dependencies in the case of code more), and the use of Di, after configuring the dependency, in the code:
@AutowiredCar car;
That is, code that handles dependencies can be omitted from the code, allowing developers to focus more on business logic.
In fact, the complexity of the program does not disappear in a vacuum, the new or new, the assembly or assembly. The original is mixed in the business logic, and the use of Di is transferred to the container. One might say that implementing a "transfer" does not require a spring container, so you can write a tool class on your own, which is used specifically to new objects, assemble objects, and then inject the assembled objects (or inject the desired objects through the setter of the business Class) into the business code by reflection. This is absolutely no problem, this is in disguise to achieve a container function, much trouble. Now that you have a ready-made spring container, you can use it directly.
You can see that the advantage of using Di is convenient. In turn, in a spring application, if you don't use container injection, you can practice it and know how troublesome it is to handle dependencies manually.
Understanding of Spring containers