"Go" Spring learning---The core principle of spring IOC container

Original

Spring's two core concepts: the embryonic form of IOC and AOP, the historical evolution of spring, and today's ecological empire.

Basic concepts of IOC and DI

IoC (inversion of control, English meaning: Inverse of controls) is the kernel of the spring container, and the functions of AOP, transaction, etc. are built on this basis. The IOC can literally be split into two meanings: control and reversal . Control can be understood as the choice of an interface implementation class, which can be understood as the option to be administered to a third party; In general, the selection control of a specific implementation class of an interface is removed from the calling class and transferred to a third party for decision, which is controlled by the spring container through the bean configuration. In this way, the application itself is not responsible for the creation and maintenance of dependent objects, but is managed by the spring container.

Although we are now familiar with the basic concepts of the IOC, in the older generation, the IOC concept is not very easy to understand. In that era, a big guy in the industry, Martin Fowler, a leading software leader, proposed the concept of Di (Dependency injection, Dependency injection) instead of IOC.

The concept of dependency injection and the concept of inversion of control are essentially the same, but they are described from different sides. The concept of dependency injection describes the dependency of the calling class on an interface implementation class with a third-party container or something else, to remove the dependency on an interface implementation class.

Today, we often say that the ioc/di of dependency injection and control inversion as the same concept to elaborate!

third, where to start the IOC container?

I have tried many times to step into the gates of spring's principles, but have been repulsed by the beginnings of no clue! Then gradually read some books gradually formed a little bit of thinking, followed by my thoughts on the main principles of the IOC container.

As we learn to ride a bicycle, we start by looking at how others ride, and then we can learn slowly (of course, the person who invented the bicycle is a genius). The same is true of spring, which only has the basic use of spring, and it is possible to step into the gates of spring's principles. So, where do we start with how we use it?

1, first look at the project structure

Inheritance Relationship:

Bean configuration:

The main code is as follows:

2, I believe that every learning spring's small partners from the above-mentioned way, the most conspicuous of the two class is the red circle out, also set us at the beginning of use, using the UML tool to display the most basic class diagram relationship:

A huge inheritance and implementation system! See here in general is also the second route I want to say (detailed in the following section)! This route shows us the Classpathxmlapplicationcontext, which is closest to developers using spring, The inheritance and implementation of layers between the Filesystemxmlapplicationcontext class and the top interface of spring.

See here we still seem to have no clue, this need we learn from previous experience, this experience is how to correctly understand the relationship between Beanfactory and ApplicationContext.

Iv. The relationship between Beanfactory and ApplicationContext

We all know that spring describes the dependencies between beans and beans by means of configuration files, annotations, Java classes, and so on, using Java's reflection function to instantiate beans and establish a dependency between beans and beans;

The underlying work is done by the spring IOC container, and the spring IOC container also provides advanced services such as bean instance caching, lifecycle management, and time release.

And here the Beanfactory and ApplicationContext are as spring IOC container of the form exists, just a little difference, simply: (1) Beanfactory interface Implementation class is a simple container Series, the container of this series only realizes the basic function of the container; (2) The implementation class of the ApplicationContext interface is a high-level container family, which adds a lot of framework-oriented features to the simple container, and makes a lot of adaptation to the application environment. A number of application-oriented features have been added, such as internationalization support and framework event architecture.

In general, we are accustomed to calling beanfactory an IOC container, while calling ApplicationContext as the application context, and sometimes we call ApplicationContext the spring container directly.

At this point, I should be able to elicit my first two routes: the first route is a simple container series based on Beanfactory, and the next day is a high-level container series based on ApplicationContext;

v. The first route: Simple container series based on Beanfactory

Since the Beanfactory implementation class is also a container, then we should be able to use it to inject our beans and get our beans, how to use Which? Please look at the code:

(1) Create an abstract resource for the IOC configuration file that contains the Beandefinition definition information (i.e., the data structure of a bean we have configured in the Bean.xml file);

(2) Create a beanfactory, here is the use of defaultlistablebeanfactory;

(3) Create a reader loaded into the beandefinition, here is the use of Xmlbeandefinitionreader to load the XML form of Beandefinition, through a callback configuration to beanfactory;

(4) Read the configuration information from the defined resource location, and the specific parsing process is done by Xmlbeandefinitionreader.

The above process, after completing the definition of the entire loading and registering bean, we need to set up the IOC container, this time we can directly use the IOC container.

The above code uses defaultlistablebeanfactory, the beanfactory default implementation of the container to complete the bean injection and fetch operations, to see its inheritance and implementation of the relationship as follows:

Beanfactory is located at the top of the interface class structure, which mainly defines the basic characteristics that should be in the IOC container, the main interface is defined as follows, according to the name can see what role, here no longer one by one explanation:

How do we understand the face of so many interfaces or classes? For a chestnut, like a car, the beanfactory defines the basic functions that the car should have, through layers of interface inheritance and implementation to customize a lot of features for this basic car architecture, such as: can seat several people, whether can reverse, etc. Until the end of the formation of a basic normal use of the car, but to this step is a relatively rough product or semi-finished products. (Can be used, but not for normal users)

The introduction of these interfaces or classes, due to limited space, here is no longer introduced, mainly to provide you with a way of thinking, how to track, master the first understanding of the spring IOC container route.

In general, Beanfactory is the spring framework's underlying setting, which is for spring itself, and the second route described below is the process used in the code above, and we rarely use the simple beanfactory-based container family directly in real-world development.

Six, the second route: ApplicationContext-based advanced container series

Compared to the semi-finished car in the first route, the product under the second route is really a car that can be opened, adding many features to the car under the ApplicationContext-based Advanced container series, such as adding electronic gears, reversing radar, panoramic skylights, Full LCD monitor What, until the end of the formation of a car can be used (can be used, ordinary users can also be used directly).

As can be seen, compared to Beanfactory ApplicationContext added a lot of new features, such as Messagesource interface, Applicationeventpublisher interface, etc. So ApplicationContext is an IOC container in a high-level morphological sense.

The primary implementation class for ApplicationContext is Classpathxmlapplicationcontext, Filesystemxmlapplicationcontext, which is loaded with a configuration file from the Classpath, The latter mode loads the configuration from the file system.

vii. Third route: Web container series based on Webapplicationcontext

From the top of the introduction we should have seen, whether the first route or the second route is based on Java applications, and we use the most is the Javaweb application, which is the next third route: based on the Webapplicationcontext Web container series.

Webapplicationcontext is specifically designed for Web applications, and because Web applications have more features than typical Java applications, Webapplicationcontext expands ApplicationContext.

When we configured spring to integrate spring MVC, we basically configured the spring container in the way described above. Contextloaderlistener gets the location of the spring configuration file through the Web container context parameter contextconfiglocation. If you are only using XML-configured beans, you will use the Webapplicationcontext implementation class Xmlwebapplicationcontext.

Viii. Summary

The purpose of this article is not to elaborate on the core principles of the spring IOC container because there are already a lot of books on the core principles of the spring IOC container, and a simple article is difficult to understand so much, here is to hope that by the spring IOC container core principles of the contents of the division, organized into 3 basic lines, so gradually break, so that they will not be a huge code structure system to frighten!

"Go" Spring learning---The core principle of spring IOC container