Spring's beanfactory architecture (i)

The code used in this article is: Spring 3.0

It's been a long time in contact with spring. However, every time you use the API directly provided by spring, you will naturally want to explore the mysteries of spring. This morning, an architecture of spring's beanfactory was sorted out (of course not complete, with Xmlfactory as the ultimate goal), such as (click to the image page):

Figure next up.

Tracing up the xmlbeanfactory, you can form the Beanfactory architecture above. Although not very comprehensive, but if this figure can understand thoroughly, I believe, Spring's beanfactory can understand thoroughly. After the series I will also take this diagram as the center, in-depth study of spring beanfactory.

The following is an understanding of each interface.

Beanfactory

This is the most primitive interface of the Beanfactory container and the most primitive client interface provided by the spring container.

Autowirecapablebeanfactory

Beanfactory with automatic assembly capability. This beanfactory is not to be used in the application, in the application to use, the use of beanfactory or listablebeanfactory. This interface is more useful for combining with other frameworks, adding beans that are not in the spring container to the spring container declaration cycle management.

It is important to note that this interface is not implemented in spring's ApplicationContext (Spring application container) because this interface is rarely used in applications.

However, you can get it through the ApplicationContext getautowirecapablebeanfactory () method. Alternatively, you can implement Beanfactoryaware (this interface is to get Beanfactory) and then convert the Beanfactory to autowirecapablebeanfactory.

Hierarchicalbeanfactory

There are levels of beanfactory. If you implement this interface, you may think you need to implement configurablebeanfactory as well. Because Configurablebeanfactory defines the method that sets the parent container, the Hierarchicalbeanfactory method only gets the method of the parent container. In general, the Configurablebeanfactory interface inherits the Hierarchicalbeanfactory directly. So, its implementation is also sure to set the parent container.

Listablebeanfactory

As the name implies, this beanfactory is able to enumerate the bean loops in the container, rather than just one by one.

If this interface is implemented with Hierarchicalbeanfactory, then the method in this interface does not consider the bean in the parent container.

It is important to note that, in addition to the Getbeandefinitioncount and Containsbeandefinition methods, other methods are best not to be called directly in the code, because their implementations can be very slow.

Singletonbeanregistry

This interface defines a container for registering singleton beans. This interface can be implemented by the Beanfactory implementation to form a unified management Singleton bean style. This interface is inherited by the Configurablebeanfactory interface.

Configurablebeanfactory

This interface defines the Beanfactory configuration feature, which is implemented by almost all beanfactory.

Similarly, this interface is not recommended for use in common application code (or Beanfactory and listablebeanfactory are recommended). This interface also gives the beanfactory the ability to expand,

Configurablelistablebeanfactory

is also configurable, but also listable beanfactory, you can implement this interface. In addition to the functionality of Configurablebeanfactory, it provides access and modification to beandefinition, pre-instantiation singletons.

Aliasregistry

Manages the public interface for aliases.

Beandefinitionregistry

Registers the interface for the beandefinition (Spring internal mapping bean's data structure).

In this system, the interface part, I look at the above. In the next article, I'll go deep into the implementation of each interface, which is the one on the right.

Spring's beanfactory architecture (i)