说明:
(1)本篇博客内容:介绍【java Config方式,实现IoC】中的对象依赖注入的问题;
(2)本篇博客的代码,沿用【Spring IoC容器与Bean管理25:使用Java Config方式实现Spring IoC一:对象实例化;(@Configuration,@Bean)】中的s09;
(3)为了应对按类型注入时的【同类型,有个对象的问题】,也可以在方法上使用@Primary注解;为了使对象是多例的,也可以在方法上使用@Scope注解;
(4)本篇博客还介绍了【java Config方式,实现IoC】和【使用注解的类】是兼容的问题,这其中涉及到了@ComponentScan;
目录
案例:【java Config方式,实现IoC】:注入对象依赖;
说明1:上面的过程是按类型注入,还是按名称注入?:先按名称注入,如果不行再按类型注入;(如果沦落到按类型注入,可以使用@Primary,来解决【同类型的多个对象问题】)
说明2:如果想让某个对象是多例的,也可以在方法上使用@Scope注解
案例:【java Config方式,实现IoC】和【使用注解的类】是兼容的;
使用@ComponentScan注解,同时去扫描和加载【使用了注解的类】;
【java Config方式,实现IoC】也可以依赖注入那些【使用注解的类】;
@ImportResource:用于加载静态配置文件,比如导入某个配置文件,让配置文件里面的内容生效;(这个没有深入介绍,以后接触到Spring Boot的时候,再深入了解吧~~)
案例:【java Config方式,实现IoC】:注入对象依赖;
需求:这个依赖注入,需要通过setter方法来实现;
……………………………………………………
解决办法:
……………………………………………………
运行结果:
……………………………………………………
说明1:上面的过程是按类型注入,还是按名称注入?:先按名称注入,如果不行再按类型注入;(如果沦落到按类型注入,可以使用@Primary,来解决【同类型的多个对象问题】)
其会先按name注入,如果不成功,则会按类型注入;
PS:因为按类型注入我们应该尽量避免,所以在方法名和属性名的对应上,我们最好对应好。
自然,万一沦落到需要按类型注入时候,为了避免【同类型的多个对象问题】我们也是可以在方法上使用@Primary注解的:
……………………………………………………
说明2:如果想让某个对象是多例的,也可以在方法上使用@Scope注解
……………………………………………………
案例:【java Config方式,实现IoC】和【使用注解的类】是兼容的;
使用@ComponentScan注解,同时去扫描和加载【使用了注解的类】;
说明:@ComponentScan:组件扫描;其作用类似于【Spring IoC容器与Bean管理21:使用注解方式实现Spring IoC二:组件类型注解(对象实例化);@Repository,@Service,@Controller,@Component;】中第一次介绍的【<context:compoment-scan>标签】的作用;
……………………………………………………
【java Config方式,实现IoC】也可以依赖注入那些【使用注解的类】;
@ImportResource:用于加载静态配置文件,比如导入某个配置文件,让配置文件里面的内容生效;(这个没有深入介绍,以后接触到Spring Boot的时候,再深入了解吧~~)
注解的Summary;
(1)【java Config方式,实现IoC】中的Config类,其作用就是完全替代applicationContext.xml的;只是,外在表现上,是通过代码方式实现的而已;
(2)【java Config方式,实现IoC】这种方式的好处:在实际使用时,因为都是java代码,如果写错了,IDEA马上就能给出错误提示,即在编译阶段就能及时发现问题。
(3)【java Config方式,实现IoC】这种方式的坏处,与【xm方式,实现IoC】和【注解方式,实现IoC】相比,【java Config方式,实现IoC】虽然开发体验更好,而且对象被集中的创建和管理,但是这毕竟是源代码,如果产品发布后需要调整,则必须要修改源代码,修改源代码就要重新测试、编译、申请、审批、上传等一系列流程;
(4)在日常工作中,【java Config方式,实现IoC】更多的用在敏捷开发中;特别适合需要快速迭代和快速上线的工程;比如,后面要接触的Spring boot框架,这个框架是Spring体系中的敏捷开发框架;Spring boot默认就基于【java Config方式,实现IoC】进行配置;
(5)【xm方式,实现IoC】和【注解方式,实现IoC】更多的是用在大型项目的团队协作中,通过配置文件将每一个功能或模块切分开,然后将切分的模块分配给不同的团队去开发,各司其职;
(6)【xm方式,实现IoC】,【注解方式,实现IoC】,【java Config方式,实现IoC】这三者,【遇到需要修改功能的时,需要修改源代码,的特性】依次增强,【开发体验】依次更好;在实际项目中,按需选择。
(7)这三种方式,扯再多没用,得实际去使用,在使用中才能更好的感受其中的优劣和选用的时机;