In this entry, how does Spring's DI container work (create objects, resolve dependent objects)? I would like to introduce the area (roughly). This entry basically assumes that you know "DI", so who is "DI" in the first place? If so, please check "DI" on the net or in books.

The contents of the illustrations introduced in this entry are the actual processing performed by Spring (determining that the essence of what you want to introduce in this entry may be impaired if accuracy is sought). Please note that there are some differences.

Write a program without using the idea of DI

Before writing a program using Spring's DI container, let's first see what happens if you write a program using multiple classes (objects) without using the idea of DI container and DI at all.

Probably ... it will look like this:

Create an A class object in the main method
Call the foo method of class A
Create a B class object in the A class foo method
Call the B class bar method

It's a very ordinary Java program.

Write a program that incorporates the idea of DI

Next ... I will write a program that incorporates the idea of DI. Specifically, let's incorporate the idea of DI into the part where the method is called after the B class object is created in the A class (the part where the dependency on the B class occurs).

Create a B class object (depending on the A class) in the main method
In the main method, pass the B class object to the constructor argument to create the A class object (= DI using the constructor)
Call the foo method of class A
Call the B class bar method

By incorporating the idea of DI into the A class, the process of creating B class objects in the A class has been eliminated. With such a configuration, the A class can perform processing using the objects of the child class of the B class in addition to the B class (for example, when performing a unit test of the A class). You will be able to use a child class of the test B class instead of the B class).

NOTE:

This entry is based on "DI using constructor", but there is also "DI using setter method" as a type of DI.

I think it is better to use the constructor and setter properly based on the following criteria (Spring Reference framework-reference / core.html # beans-factory-collaborators) is a sale w).

Constructor for DI required

If DI is arbitrary (there is an object to be used by default and DI is treated as an option), the setter method

If you are aware of the above usage, the usage image will look like the one below.

When executing via the Bootstrap class, use the "B object created in advance in the A object" as it is, and when executing via the test class, DI (replace) the "B object for testing". I tried to configure it to use.

Although not introduced in this entry, Spring also has a mechanism to "DI directly to the field" (as a recent trend, it seems that "DI to the field" is not used. However, the amount of code is small because it is "DI to the field" ... I sometimes use it unintentionally w).

Write a program using Spring DI container

Now that we've modified the class we're using to a DI-capable class, let's see what happens when we write a program using Spring's DI container (await !?).

Creating a bean definition class

Before modifying the program ... Make the part that creates the objects of the classes (A class and B class) used in the program into a Bean definition class (configuration class).

Modified the program to use DI container

After creating the bean definition class, create a DI container (application context) and modify the program to get the bean (A class object) of the class that is the entry point of the actual processing from the DI container.

Operation image when using DI container

Now that you're ready to use Spring's DI container, let's see how Spring's DI container works.

Create a DI container (application context). The application context reads the contents of the Bean definition class passed to the argument of the constructor, creates a bean (object), and manages it in the DI container.
A method that creates a B-class bean with no dependencies is called
Create a B-class object (added to the DI container)
The method to generate the A class bean is called with the B class bean managed by the DI container as an argument
Pass the B class bean to the constructor argument to create an A class object (= DI using the constructor)
After the DI container generation is completed, get the Bean of the class (A class) that is the entry point of the actual processing from the DI container.
Call the foo method of "A class bean obtained from DI container"
Call the bar method of the "B class bean" that was DI to the "A class bean by the DI container"

Define beans using the component scan function

I modified the program to use Spring's DI container, but in the actual application, it is almost impossible to use only two classes ... I will use a larger number of classes. At that time ... It seems difficult to define a method to generate a bean in the Bean definition class (in the figure: MyConfig class)! ?? If you find the bean definition difficult, you can simplify the bean definition by using the component scan function. In particular···

Specify " @ ComponentScan "in the Bean definition class to enable the component scan function * Specify the attribute if necessary
Specify " @ Component "(or @Service or other annotation with @Component) for the class you want to scan.

please.

The overall flow is the same as when the component scan function is not used, but the process for generating beans (processes (2) to (4) in the figure) is different. When using the component scan function, the bean definition is determined from the metadata (class annotation, method annotation, etc.) of the scanned class and the bean is generated.

Sample program

Although the contents are slightly different, the sample of the contents introduced in this entry is stored in the following repository.

https://github.com/kazuki43zoo/spring-di-demo

Summary

This time, I introduced the operation image when using Spring DI container. The content introduced in this entry is only a part (touch part) of the whole picture of Spring DI container, and in order to effectively utilize the functions provided by DI container, "Bean scope" and "Bean priority" It is also necessary to have knowledge about the mechanism such as "initialization process / discard process", "AOP (Proxy)", and "profile", but by reading this entry, the first step of application development using Spring DI container. I would appreciate it if you could take a step forward: grin :.

Actually, you can develop an application by "imitation" without knowing the mechanism of DI container, but: sweat_smile: ..., if you do not hold the basics properly (anything), "there is nothing to imitate" You may end up with an engineer who freezes at times. Immediate "results" are important (although there are times when you have to prioritize them), but it is very important to understand how your program works as an application (= operating principle). I think it's important. If it's working for the time being, but you don't know how it's working (= it's moody), you can stop and learn the basics to get rid of that moody, and you can't see it until now (notice). I think you can see what I couldn't do.

[JAVA] Let's grasp the operation image (atmosphere) of the DI container of Spring