BeanFactory and ApplicationContext in Spring

In my tutorials about Spring framework, I often use the object of the ApplicationContext interface as a Spring container to call the object that I need to retrieve. For example, in the previous tutorial:

But in fact, Spring also provides us with another interface that the implementation object actually is the Spring container, called BeanFactory.

So now, if you replace the ApplicationContext:

by BeanFactory as the following code:

Then the results are as normal when you run.

So what’s the difference between these two interfaces? Why did I only use the ApplicationContext without beating the BeanFactory? In this tutorial, I will clarify to you guys!

The first thing I would like to say is that the ApplicationContext interface extends from the BeanFactory interface, but BeanFactory only provides the basic functionality for Dependency Injection in Spring, while the ApplicationContext has other more advanced features.

The first difference in these two interfaces is that they both provide the ability to retrieve the object we need in Spring’s container using the getBean() method, but the BeanFactory only produces the object we need when we call its getBean() method and ApplicationContext will create all the objects we need as soon as we call to Spring container.

To prove this, I will continue the example that I did in the previous tutorial.

OK, now I need to know when calling to Spring container, what does it do? At DEBUG level, Spring will tell us all about that.

So I will add the log4j library to my existing project and configure our program to run at DEBUG level. As follows:

The contents of the log4j.properties file:

Add dependency of log4j library to pom.xml file:

Now in the main method of the Application class, we will remove all the code except for the code that calls to the Spring container, which means that the Application class just has content as follows:

Now when I run the application, you’ll see the following logs:

If you take a close look at these logs, you will see that when you call the Spring container using the ApplicationContext, all objects declared in the Spring configuration file are instantiated.

Now, we will use BeanFactory instead of ApplicationContext. The contents of the application file will be as follows:

Then run, observe the logs:

You will see that no object is created at all.

If you now add the getBean() code, our object will be created in the Spring container:

Log content:

The second difference between these two interfaces is in their implementation. For BeanFactory we often use the object that implements it as XmlBeanFactory and the ApplicationContext is ClassPathXmlApplicationContext.

The third difference between these two interfaces is the ability to support multiple languages. For example, you have a sentence translated into three different languages: a Vietnamese, an English, a French. ApplicationContext gives us the ability to derive the contents of this statement in three different languages using the getMessage(String code, Object [] args, Locale local) method, while BeanFactory does not support us to do this.

In addition, there are a number of different points between these two interfaces, but since this tutorial is long, these different points must have specific examples for you to understand, then I should not be listed here.

In this tutorial, my goal is to tell you that: in addition, calling to Spring container using the ApplicationContext, we can also use the BeanFactory. ApplicationContext supports more powerful functions so most of us use this interface.