Anyone who has learned Spring framework must have heard of Spring's two concepts: IoC (control inversion) and DI (dependency injection). For those who are new to Spring, they always feel that the concepts of IoC and DI are vague and difficult to understand. Today, I will share with you some of the online technical experts' understanding of Spring framework IOC and talk about my understanding of Spring Ioc.
What is IoC
Ioc-InversionofControl, that is, "control inversion", is not a technology, but a design idea. In Java development, Ioc means giving the objects you designed to be controlled by containers, rather than traditionally controlling them directly inside your objects.
IoC, which is the core of spring, runs through the whole time. For the spring framework, spring is responsible for controlling the life cycle of an object and the relationship between objects. What does this mean? To give a simple example, how do we find a girlfriend? A common situation is that we go everywhere to see where we have beautiful and good-looking women, and then inquire about their interests, QQ numbers, phone numbers, IP numbers, iQ numbers..., find ways to get to know them, give them what they like, and then hehe... This process is complex and profound, and we must design and face each link ourselves. The same is true for traditional program development. In an object, if you want to use another object, you must get it (new one by yourself, or query one from JNDI). After use, the object must be destroyed (such as Connection, etc.), and the object will always be combined with other interfaces or classes.
How to understand Ioc? The key to understanding Ioc is to clarify "who controls who, what controls, why is it a reversal (there should be a positive one), and what aspects of reversal are there", let's analyze in depth:
●Who controls whom and what: Traditional JavaSE programming design, we create objects directly through new within the object, and the program actively creates dependent objects; while IoC has a special container to create these objects, that is, the Ioc container controls the creation of objects; who controls whom? Of course, the IoC container controls the object; what to control? That is, it mainly controls the acquisition of external resources (not just objects including files, etc.).
●Why is it inversion? What aspects are inversion: there is a positive rotation. Traditional applications are actively controlled by ourselves in the object to directly obtain the dependent object, that is, the positive rotation; while inversion is the container to help create and inject dependent objects; why is it inversion? Because the container helps us find and inject dependent objects, the object only passively accepts dependent objects, so it is an inversion; what aspects are inversions? The acquisition of the dependent object is reversed.
Let’s use legend to illustrate that traditional programming is shown in Figure 1-1, which actively creates related objects and then combines them:
Figure 1-1 Schematic diagram of traditional application
When I have IoC/DI containers, these objects are no longer actively created in the client class, as shown in Figure 1-2:
Figure 1-2 Schematic diagram of the program structure after the IoC/DI container has IoC/DI container
1.1.2 What can IoC do
IoC is not a technology, it is just a thought, an important rule of object-oriented programming, which can guide us how to design loosely coupled, better programs. Traditional applications are all actively created by us within the class, which leads to high coupling between classes and difficult to test; with the IoC container, the control of creating and finding dependent objects is handed over to the container, and the container injects the combined objects, so the object is loosely coupled, which is also convenient for testing, facilitates functional reuse, and more importantly, makes the entire architecture of the program very flexible.
In fact, the biggest change brought by IoC to programming is not from the code, but from the ideological perspective, and the change of "master-slave transposition". The application was originally the boss, and he took the initiative to obtain any resources. However, in the IoC/DI idea, the application became passive, and he was passively waiting for the IoC container to create and inject the resources it needed.
IoC well reflects one of the rules of object-oriented design - the Hollywood rule: "Don't look for us, we'll look for you"; that is, the IoC container helps the object find the corresponding dependent object and inject it, rather than the object actively looking for it.
1.1.3 IoC and DI
DI-DependencyInjection, that is, "dependency injection": the dependencies between components are determined by the container during the runtime. In figuratively, the container dynamically injects a certain dependency into the component. The purpose of dependency injection is not to bring more functions to the software system, but to increase the frequency of component reuse and build a flexible and scalable platform for the system. Through the dependency injection mechanism, we only need to specify the resources required by the target without any code to complete our own business logic through simple configuration, without caring about where the specific resources come from and who implement them.
One of the key points of IoC is to dynamically provide an object with other objects it needs during the system operation. This is achieved through DI (Dependency Injection). For example, object A needs to operate the database. In the past, we always wrote code in A to obtain a Connection object. With spring, we only need to tell spring that a Connection is needed in A. As for how to construct this Connection and when to construct it, A does not need to know. When the system is running, spring will create a Connection at the appropriate time, and then inject it into A like an injection, thus completing the control of the relationship between each object. A needs to rely on Connection to run normally, and this Connection is injected into A by spring, and the name of dependency injection comes from this. So how is DI implemented? An important feature after Java 1.3 is reflection, which allows the program to dynamically generate objects, execute objects methods, and change objects' properties when running. Spring is injected through reflection.
The key to understanding DI is: "Who depends on who, why do you need to depend on it, who injects who, and what injects it." Let's analyze it in depth:
●Who depends on whom: Of course, the application depends on the IoC container;
●Why dependencies are needed: Applications need IoC containers to provide external resources required by objects;
●Who injects whom: It is obvious that the IoC container injects an object of the application, an object that the application depends on;
●What is injected: it is to inject external resources (including objects, resources, and constant data) required for an object.
What is the relationship between IoC and DI? In fact, they are described from different angles from the same concept. Since the concept of control inversion is relatively vague (maybe it is understood as the level of container control objects, it is difficult to think of who will maintain object relationships), in 2004, the master Martin Fowler gave a new name: "Dependency injection". Compared with IoC, "Dependency injection" clearly describes "the injected object depends on the IoC container configuration dependency object".
Summarize
In fact, everyone has their own understanding of the concept of Spring IOC, and there is no standard answer. The general direction is just right.
The above is all about understanding dependency injection and control inversion in Spring. I hope it will be helpful to everyone. If there are any shortcomings, please leave a message to point it out. Thank you friends for your support for this site!