Users are sometimes unsure whether a BeanFactory or an ApplicationContext is best suited for use in a particular situation. A BeanFactory pretty much just instantiates and configures beans. An ApplicationContext also does that, and it provides the supporting infrastructure to enable lots of enterprise-specific features such as transactions and AOP.
use an ApplicationContext unless you have a really good reason for not doing so. For those of you that are looking for slightly more depth as to the ´but why´ of the above recommendation.
As the ApplicationContext includes all functionality of the BeanFactory, it is generally recommended that it be used in preference to the BeanFactory, except for a few limited situations such as in an Applet, where memory consumption might be critical and a few extra kilobytes might make a difference. However, for most ´typical´ enterprise applications and systems, the ApplicationContext is what you will want to use. Versions of Spring 2.0 and above make heavy use of the BeanPostProcessor extension point (to effect proxying and suchlike), and if you are using just a plain BeanFactory then a fair amount of support such as transactions and AOP will not take effect (at least not without some extra steps on your part), which could be confusing because nothing will actually be wrong with the configuration.
Find below a feature matrix that lists what features are provided by the BeanFactory and ApplicationContext interfaces (and attendant implementations). (The following sections describe functionality that ApplicationContext adds to the basic BeanFactory capabilities in a lot more depth than the said feature matrix.)
|Automatic BeanPostProcessor registration||No||Yes|
|Automatic BeanFactory PostProcessor registration||No||Yes|
|Convenient MessageSource access (for i18n)||No||Yes|