The differences between BeanFactory, FactoryBean, and ApplicationContext that are often asked in interviews

To a certain extent, Java programmers can be said to be Spring programmers. In daily development work, it is estimated that they are either tossing Spring Family Bucket or integrating various frameworks with Spring. As a Spring programmer, I was asked about BeanFactory and FactoryBean in the interview. , and the difference between applicationContext and applicationContext is quite likely. Today I will talk about some personal understandings. If you don’t like it, don’t criticize it. Corrections are welcome.

We know that the core of Sping is IOC and AOP. AOP is a supplement to IOC, or some extensions based on IOC to facilitate some general logic processing that is not so closely related to business logic, such as transactions, logging, etc. Wait, and the cornerstone of IOC is BeanFactory. We can look at the definition of BeanFactory:

 BeanFactory, as the top-level interface of Spring IOC container, only contains some Bean read-only operations (various get), but these are far from enough, so spring provides ApplicationContext. We are looking at the definition of ApplicationContext:

 We can see that ApplicationContext indirectly inherits BeanFactory, and also inherits other interfaces, such as internationalization, event listeners, resource parsers, etc. Compared with BeanFactory, we can see that ApplicationContext has much richer functions, so in general ,that is

BeanFactory is the top-level interface of the Spring container, which only contains some simple read operations of Bean, while ApplicationContext not only contains all the functions of BeanFactory, but also extends functions such as internationalization.

So what's going on with FactoryBean?

We know that under normal circumstances, in Spring, the creation process of a Bean is very complicated, and the life cycle of the entire Bean is also very long. So is there a way to simplify the creation of the Bean and at the same time hand the Bean over to Spring for management? , FactoryBean is born for this. By implementing the FactoryBean interface, we can create custom beans:

@Component
public class ServiceBFactory implements FactoryBean<ServiceB> {
    @Override
    public ServiceB getObject() throws Exception {
        return new ServiceB();
    }

    @Override
    public Class<?> getObjectType() {
        return ServiceB.class;
    }

    @Override
    public boolean isSingleton() {
        return true;
    }
}

The above code can implement a simple custom bean creation process, which is much simpler than leaving the entire process of ordinary beans to Spring (spring needs to talk about instantiation, initialization, and dynamic proxy when creating ordinary beans. etc)

The second function of FactoryBean is to facilitate the integration of third-party frameworks and Spring. We know that most of the current Java programs are related to Spring, so other frameworks will inevitably embrace Spring when using them. , then the development of this integration can only be implemented by the third-party framework itself, rather than letting Spring do it, such as mybatis, dubbo, hibnernate, etc. Of course, the third-party framework can not only integrate with Spring through FactoryBean Implementation, what I know so far is that there are two ways, one is to customize tags such as dubbo, and the other is through FactoryBean, such as mybatis (in fact, mybatis implements both methods, but we usually use it more It’s FactoryBean, I’ll talk about this later when I have the opportunity)

To sum up: FactoryBean is to simplify the bean creation process and facilitate the integration of third-party frameworks with Spring.

PS: Beans created through FactoryBean are not stored in the first-level cache in what we often call Spring's third-level cache (ordinary beans are placed in the first-level cache after they are created)