In this tutorials we are going to see why ApplicationContext container is better than BeanFactory container.
The ApplicationContext includes all the functionality of BeanFactory, it is generally recommended over the BeanFactory, except for few situations such as in an Applet where memory consumption might be critical and few extra KB might make difference. However, for typical enterprise applications and systems, the ApplicationContext is what you will want to you want to use.
The Spring 2.0 and later makes heavy use of the BeanPostProcessor point (to effect proxying and so on). i f you use only a plain BeanFactory, a fair amount of support such as transactions and AOP will not take effect, at least not without some extra steps on your part. This situation could be confusing because nothing is actually wrong with the configuration.
The table given below list the comparison between BeanFactory and ApplicationContext interface and implementations.
To explicitly register a bean post-processor with a BeanFactory implementation, you must write code like this:
To explicitly register a BeanFactoryPostProcessor when using a BeanFactory implementation, you must write code like this:
In both cases, the explicit registration step is inconvenient, which is one reason why the various ApplicationContext implementations are preferred above plain BeanFactory implementations in the vast majority of Spring-backed applications, especially when using BeanFactoryPostProcessors and BeanPostProcessors. These mechanisms implement important functionality such as property placeholder replacement and AOP.
The ApplicationContext includes all the functionality of BeanFactory, it is generally recommended over the BeanFactory, except for few situations such as in an Applet where memory consumption might be critical and few extra KB might make difference. However, for typical enterprise applications and systems, the ApplicationContext is what you will want to you want to use.
The Spring 2.0 and later makes heavy use of the BeanPostProcessor point (to effect proxying and so on). i f you use only a plain BeanFactory, a fair amount of support such as transactions and AOP will not take effect, at least not without some extra steps on your part. This situation could be confusing because nothing is actually wrong with the configuration.
The table given below list the comparison between BeanFactory and ApplicationContext interface and implementations.
Feature
|
BeanFactory
|
ApplicationContext
|
Bean instantiation/wiring | Yes | Yes |
Automatic BeanPostProcessor registration | No | Yes |
Automatic BeanFactoryPostProcessor registration | No | Yes |
Convenient MessageSource access (for i18n) | No | Yes |
ApplicationEvent publication | No | Yes |
ConfigurableBeanFactory factory = new XmlBeanFactory(...); // now register any needed BeanPostProcessor instances MyBeanPostProcessor postProcessor = new MyBeanPostProcessor(); factory.addBeanPostProcessor(postProcessor); // now start using the factory
To explicitly register a BeanFactoryPostProcessor when using a BeanFactory implementation, you must write code like this:
XmlBeanFactory factory = new XmlBeanFactory(new FileSystemResource("beans.xml")); // bring in some property values from a Properties file PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer(); cfg.setLocation(new FileSystemResource("jdbc.properties")); // now actually do the replacement cfg.postProcessBeanFactory(factory);
In both cases, the explicit registration step is inconvenient, which is one reason why the various ApplicationContext implementations are preferred above plain BeanFactory implementations in the vast majority of Spring-backed applications, especially when using BeanFactoryPostProcessors and BeanPostProcessors. These mechanisms implement important functionality such as property placeholder replacement and AOP.
0 comments:
Post a Comment