Spring Core mechanism: Dependency Injection

Control inversion (inversion of the English abbreviation for IOC) is an important object-oriented programming principle to reduce the coupling problem of computer programs, and is also the core of the lightweight spring framework. Control reversals are generally divided into two types, dependency injection (Dependency injection, short di), and dependent lookup (Dependency lookup). The application of dependency injection is quite extensive.

With dependency injection, you can inject common attribute values for a bean, and you can inject references from other beans as well. By using this dependency injection, the various components in the Java EE application do not need to be coupled in a hard-coded fashion, or even use Factory mode, and when a Java instance needs another instance, the system automatically provides the required instance without the need for the program to get it explicitly.

Spring uses dependency injection very well, but spring is not the first to rely on injection, nor is it the only choice. In spring, whether it's dependency injection or control inversion, their meaning is exactly the same, and in the traditional design process, the caller's instance is typically created by a particular Java instance when another Java instance is needed. In a dependency injection pattern, the creation of the callee's work is not done by the caller, so called inversion of control: the work of creating the callee instance is usually done by the spring container and then injected into the caller, so it is also called dependency injection. Whether it's dependency injection or control inversion, it shows that spring uses dynamic, flexible ways to manage objects, and the concrete implementations of objects and objects are transparent to each other.

To create a Java object, in the first case, the caller of the Java instance creates the invoked Java instance, the caller creates the callee instance directly using the New keyword, the program is highly coupled, inefficient, and is generally not used in real-world applications. This way is a beginner's preferred way of using, like the following two disadvantages: 1, the scalability of poor. 2, the responsibility of each component is unclear. In the second case, the caller does not need to be concerned about the specific implementation process of the callee, but only needs to find an instance that conforms to a certain standard and can be used. In this case, the code being called is interface-oriented, allowing the caller and callee to decouple, which is why the factory pattern is heavily used. But the caller needs to proactively locate the factory, and the caller and the factory are coupled together. The third situation is the most ideal, the program completely ignore the implementation of the caller, but also do not have to actively locate the factory, this is the best way to decouple. The dependencies between instances are managed by the IOC container.

Dependency injection, which means that in the course of running a program, if you need another object collaboration (including the method that calls it to access his properties), you do not need to create the callee in your code, but instead rely on the injection of the outer container. Spring's dependency injection has virtually no requirement for callers and callers to fully support the management of dependencies between Pojo. Dependency injection usually has value injection and construction injection.

IOC container concept: The IOC container is a container with dependency injection capabilities, and IOC containers are responsible for instantiating, locating, configuring objects in the application, and establishing dependencies between those objects. Applications do not need to be directly related to new objects in the code, and the application is assembled by an IOC container. Beanfactory is the actual representative of the IOC container in spring. How does the Spring IOC container know which objects it manages? This requires a configuration file, and the Spring IOC container instantiates and assembles individual objects in the application by reading the configuration metadata from the configuration file. Configuration metadata is typically used based on an XML configuration file, and spring is fully decoupled from the configuration file, and can be configured in any other way possible, such as annotations, Java file-based configuration, and property file-based configurations. IOC is not a technology, but an idea, an important object-oriented programming law that can guide us in designing loosely coupled, better programs. Traditional applications are created by us to create dependent objects within the class, which causes the class to be highly coupled to the class and difficult to test; with the IOC container, the control of creating and finding dependent objects is given to the container, which is injected by the container, so that the object is loosely coupled with the object, so it is also easy to test. Facilitates functional reuse and, more importantly, makes the entire architecture of the program very flexible. In fact, the biggest change of the IOC to programming is not from the code, but from the thought, the "master-slave Transposition" change. The application was originally the boss, to get what resources are active attack, but in Ioc/di thought, the application becomes passive, passively wait for the IOC container to create and inject the resources it needs.
IOC is a good embodiment of the object-oriented design of one of the rules of Hollywood: "Do not call us, we find you", that is, the IOC container for the object to find the corresponding dependent objects and injected, rather than the object to be actively looking for.

This blog reference from: "Lightweight Java EE Enterprise Application Combat" Li Gang

http://jinnianshilongnian.iteye.com/blog/1413846

Spring Core mechanism: Dependency Injection