IoC、DI和AOP思想概要
回顾IoC和DI思想(控制反转、依赖注入和BeanFactory回忆)
第一步:引入spring的maven坐标
可见引入spring-context坐标后,aop、beans和core等关键依赖也引入了
第二步:书写接口和实现类
假设我们有一个UserService,它有个实现类是impl包下的UserServiceImpl。
第三步:书写配置文件
第一,配置文件配置在bean工厂中配置了两个bean,注意这里配置的bean不是接口,而是接口的实现类,例如下面我们配置了一个id为userService的bean,class属性表示反射对应的实现类,是impl包下的UserServiceImpl,因为UserServiceImpl实现了UserService接口,在之后使用beanFactory实例化UserService接口时,Spring会基于配置信息主动创建一个UserService接口在bean工厂中的实现类。(控制反转)
第二,如果UserService现在能不能满足需求,要引入其它依赖,如果按照以往的思路,是直接在UserService中new一个需要的对象,但是显然这是不满足我们Spring思想的,这时我们需要在bean配置文件中做进一步的配置。在UserService中提供setter方法(如下,起名什么都行,但必须满足setter命名规范)在UserService的bean标签中增加property标签,name属性与setter名对应,ref属性表示要为这个setter方法对应注入什么bean,所以ref填的是bean工厂中其它bean的id。(依赖注入)
ApplicationContext回忆
ApplicationConstex在实际开发过程中接触得比BeanFactory多得多,比BeanFactory功能更丰富更强大,但其底层是实现了BeanFactory。
BeanFactory与ApplicationContext之间的关系
BeanFactory称为Spring的Bean工厂,而ApplicationContext称为Spring容器,从名字上,工厂意思是制造,容器意思是使用,这一点也体现在Bean的初始化时机中,BeanFactory是在首次调用getBean时才进行Bean的创建,而ApplicationContext则在配置文件加载、容器创建后就将Bean都实例化并初始化好,当然配置文件加载、容器创建在整个项目运行之初就完成了,所有ApplicationContext在获取Bean上相较于BeanFactory更强大。
BeanFactory相对于ApplicationContext更加底层,在如下的继承树中,BeanFactory是最底层的,ApplicationContext除了继承BeanFactory所有的能力外,还继承了ApplicationEventPublisher(事件发布器,与监听机制相关),ResourcePatternResolver(资源解析器)等。所以ApplicationContext相较于BeanFactory要强大很多。
BeanFactory和ApplicationContext继承体系
当只有Spring基础环境下(只导入了Spring-Context依赖时),ApplicationConstext接口的继承体系中,有三个实现类可以使用,当Spring配置使用注解配置时,Spring客户端使用AnnotationConfigApplicationContex实现类,当Spring配置使用xml配置时,Spring客户端使用FileSystemXmlApplicationContex或ClassPathXmlApplicationContext。