BeanFactory 和 ApplicationContext的区别
2016-02-03 15:43
393 查看
今天在网上查资料无意中看到这一行代码
平时用的是这个
这与平时学的稍微有点差别, 处于好奇, 便在网上看了看这两中写法有啥不一样的地方, 找了一些自己能理解的, 这些区别还不是很全, 以后再看
1).BeanFactroy采用的是延迟加载形式来注入Bean的,即只有在使用到某个Bean时(调用getBean()),才对该Bean进行加载 实例化,这样,我们就不能发现一些存在的Spring的配置问题。而ApplicationContext则相反,它是在容器启动时,一次性创建了所有的 Bean。这样,在容器启动时,我们就可以发现Spring中存在的配置错误。
下面是不是很理解的:
原文引自:
http://blog.csdn.net/hi_kevin/article/details/7325554
1.利用MessageSource进行国际化
BeanFactory是不支持国际化功能的,因为BeanFactory没有扩展Spring中MessageResource接口。相反,由于
ApplicationContext扩展了MessageResource接口,因而具有消息处理的能力(i18N),具体spring如何使用国际
化,以后章节会详细描述。
2.强大的事件机制(Event)
基本上牵涉到事件(Event)方面的设计,就离不开观察者模式。不明白观察者模式的朋友,最好上网了解下。因为,这种模式在java开发中是比较常用的,又是比较重要的。
ApplicationContext的事件机制主要通过ApplicationEvent和ApplicationListener这两个接口来提供
的,和java
swing中的事件机制一样。即当ApplicationContext中发布一个事件的时,所有扩展了ApplicationListener的
Bean都将会接受到这个事件,并进行相应的处理。
Spring提供了部分内置事件,主要有以下几种:
ContextRefreshedEvent :ApplicationContext发送该事件时,表示该容器中所有的Bean都已经被装载完成,此ApplicationContext已就绪可用
ContextStartedEvent:生命周期 beans的启动信号
ContextStoppedEvent: 生命周期 beans的停止信号
ContextClosedEvent:ApplicationContext关闭事件,则context不能刷新和重启,从而所有的singleton bean全部销毁(因为singleton bean是存在容器缓存中的)
虽然,spring提供了许多内置事件,但用户也可根据自己需要来扩展spriong中的事物。注意,要扩展的事件都要实现ApplicationEvent接口。
3.底层资源的访问
ApplicationContext扩展了ResourceLoader(资源加载器)接口,从而可以用来加载多个Resource,而BeanFactory是没有扩展ResourceLoader
4.对Web应用的支持
与BeanFactory通常以编程的方式被创建不同的是,ApplicationContext能以声明的方式创建,如使用
ContextLoader。当然你也可以使用ApplicationContext的实现之一来以编程的方式创建ApplicationContext
实例 。
ContextLoader有两个实现:ContextLoaderListener和ContextLoaderServlet。
它们两个有着同样的功能,除了listener不能在Servlet 2.2兼容的容器中使用。自从Servelt
2.4规范,listener被要求在web应用启动后初始化。很多2.3兼容的容器已经实现了这个特性。使用哪一个取决于你自己,但是如果所有的条件都
一样,你大概会更喜欢ContextLoaderListener;关于兼容方面的更多信息可以参照ContextLoaderServlet的JavaDoc。
这个listener需要检查contextConfigLocation参数。如果不存在的话,它将默认使用/WEB-INF/applicationContext.xml。如果它存在,
它就会用预先定义的分隔符(逗号,分号和空格)分开分割字符串,并将这些值作为应用上下文将要搜索的位置。ContextLoaderServlet可以
用来替换ContextLoaderListener。这个servlet像listener那样使用contextConfigLocation参数。
5.其它区别
1).BeanFactroy采用的是延迟加载形式来注入Bean的,即只有在使用到某个Bean时(调用getBean()),才对该Bean进行加载
实例化,这样,我们就不能发现一些存在的Spring的配置问题。而ApplicationContext则相反,它是在容器启动时,一次性创建了所有的
Bean。这样,在容器启动时,我们就可以发现Spring中存在的配置错误。
2).BeanFactory和ApplicationContext都支持BeanPostProcessor、
BeanFactoryPostProcessor的使用,但两者之间的区别是:BeanFactory需要手动注册,而
ApplicationContext则是自动注册
BeanFactory factory = new ClassPathXmlApplicationContext("applicationContext.xml");
平时用的是这个
ApplicationContext applicationcontext = new ClassPathXmlApplicationContext("applicationContext.xml");
这与平时学的稍微有点差别, 处于好奇, 便在网上看了看这两中写法有啥不一样的地方, 找了一些自己能理解的, 这些区别还不是很全, 以后再看
1).BeanFactroy采用的是延迟加载形式来注入Bean的,即只有在使用到某个Bean时(调用getBean()),才对该Bean进行加载 实例化,这样,我们就不能发现一些存在的Spring的配置问题。而ApplicationContext则相反,它是在容器启动时,一次性创建了所有的 Bean。这样,在容器启动时,我们就可以发现Spring中存在的配置错误。
下面是不是很理解的:
原文引自:
http://blog.csdn.net/hi_kevin/article/details/7325554
1.利用MessageSource进行国际化
BeanFactory是不支持国际化功能的,因为BeanFactory没有扩展Spring中MessageResource接口。相反,由于
ApplicationContext扩展了MessageResource接口,因而具有消息处理的能力(i18N),具体spring如何使用国际
化,以后章节会详细描述。
2.强大的事件机制(Event)
基本上牵涉到事件(Event)方面的设计,就离不开观察者模式。不明白观察者模式的朋友,最好上网了解下。因为,这种模式在java开发中是比较常用的,又是比较重要的。
ApplicationContext的事件机制主要通过ApplicationEvent和ApplicationListener这两个接口来提供
的,和java
swing中的事件机制一样。即当ApplicationContext中发布一个事件的时,所有扩展了ApplicationListener的
Bean都将会接受到这个事件,并进行相应的处理。
Spring提供了部分内置事件,主要有以下几种:
ContextRefreshedEvent :ApplicationContext发送该事件时,表示该容器中所有的Bean都已经被装载完成,此ApplicationContext已就绪可用
ContextStartedEvent:生命周期 beans的启动信号
ContextStoppedEvent: 生命周期 beans的停止信号
ContextClosedEvent:ApplicationContext关闭事件,则context不能刷新和重启,从而所有的singleton bean全部销毁(因为singleton bean是存在容器缓存中的)
虽然,spring提供了许多内置事件,但用户也可根据自己需要来扩展spriong中的事物。注意,要扩展的事件都要实现ApplicationEvent接口。
3.底层资源的访问
ApplicationContext扩展了ResourceLoader(资源加载器)接口,从而可以用来加载多个Resource,而BeanFactory是没有扩展ResourceLoader
4.对Web应用的支持
与BeanFactory通常以编程的方式被创建不同的是,ApplicationContext能以声明的方式创建,如使用
ContextLoader。当然你也可以使用ApplicationContext的实现之一来以编程的方式创建ApplicationContext
实例 。
ContextLoader有两个实现:ContextLoaderListener和ContextLoaderServlet。
它们两个有着同样的功能,除了listener不能在Servlet 2.2兼容的容器中使用。自从Servelt
2.4规范,listener被要求在web应用启动后初始化。很多2.3兼容的容器已经实现了这个特性。使用哪一个取决于你自己,但是如果所有的条件都
一样,你大概会更喜欢ContextLoaderListener;关于兼容方面的更多信息可以参照ContextLoaderServlet的JavaDoc。
这个listener需要检查contextConfigLocation参数。如果不存在的话,它将默认使用/WEB-INF/applicationContext.xml。如果它存在,
它就会用预先定义的分隔符(逗号,分号和空格)分开分割字符串,并将这些值作为应用上下文将要搜索的位置。ContextLoaderServlet可以
用来替换ContextLoaderListener。这个servlet像listener那样使用contextConfigLocation参数。
5.其它区别
1).BeanFactroy采用的是延迟加载形式来注入Bean的,即只有在使用到某个Bean时(调用getBean()),才对该Bean进行加载
实例化,这样,我们就不能发现一些存在的Spring的配置问题。而ApplicationContext则相反,它是在容器启动时,一次性创建了所有的
Bean。这样,在容器启动时,我们就可以发现Spring中存在的配置错误。
2).BeanFactory和ApplicationContext都支持BeanPostProcessor、
BeanFactoryPostProcessor的使用,但两者之间的区别是:BeanFactory需要手动注册,而
ApplicationContext则是自动注册
相关文章推荐
- 微信2015 年最热门的 10 篇技术文章,共 100 多篇精华
- 优化 Android 线程和后台任务开发
- Xcode 7 beta发布,Swift 2.0带来哪些新变化?
- 隐藏APP图标
- [Linphone Android]LinphoneService分析@onCreate
- Android中adb命令
- Android 测试 Appium、Robotium、monkey等框架或者工具对比
- ViewPager 图片切换
- 新编辑器Cocos Creator发布:对不起我来晚了!
- 微信企业号开发(七)---图片上传与下载
- 【独家】2015年App Store审核被拒的23个理由(附官方邮件原文)
- Swift最酷炫的七大功能
- Android实战技巧之四十八:Android上的Java8和kotlin
- 微信公众平台,网页授权及 40029 问题解决
- Android LayoutInflater源码解析
- cocos2d-x 3.6版连连看
- 3D版的TagView,效果很赞
- Android抽象布局——include、merge 、ViewStub
- Android初学习 - visibility属性VISIBLE、INVISIBLE、GONE
- LeakCanary——直白的展现Android中的内存泄露