BeanFactory subclass such as an {@link org.springframework.context.ApplicationContext}. Where this interface is implemented as a singleton class such as {@link SingletonBeanFactoryLocator}, the Spring team strongly suggests that it be used sparingly and with caution. By far the vast majority of the code inside an application is best written in a Dependency Injection style, where that code is served out of a BeanFactory/ApplicationContext container, and has its own dependencies supplied by the container when it is created. However, even such a singleton implementation sometimes has its use in the small glue layers of code that is sometimes needed to tie other code together. For example, third party code may try to construct new objects directly, without the ability to force it to get these objects out of a BeanFactory. If the object constructed by the third party code is just a small stub or proxy, which then uses an implementation of this class to get a BeanFactory from which it gets the real object, to which it delegates, then proper Dependency Injection has been achieved.
As another example, in a complex J2EE app with multiple layers, with each layer having its own ApplicationContext definition (in a hierarchy), a class like SingletonBeanFactoryLocator may be used to demand load these contexts.
@author Colin Sampaleanu
@see org.springframework.beans.factory.BeanFactory
@see org.springframework.context.access.DefaultLocatorFactory
@see org.springframework.context.ApplicationContext
| |