仿springboot Autowired自动注入

老铁们,大家好,相信还有很多朋友对于SpringBoot中,@Autowired和@Resource使用起来到底有什么区别和autowired不建议使用的相关问题不太懂,没关系,今天就由我来为大家分享分享SpringBoot中,@Autowired和@Resource使用起来到底有什么区别以及autowired不建议使用的问题,文章篇幅可能偏长,希望可以帮助到大家,下面一起来看看吧!

本文目录

  1. idea如何引入spring Context
  2. SpringBoot中,@Autowired和@Resource使用起来到底有什么区别
  3. spring中普通类调用service类怎么调用

idea如何引入spring Context

idea引入springContext:

1、首先,可以点击上方的Run的选项。

2、然后点击EditConfigurations这个选项。

3、然后看到这里的ServiceApplication这个选项。

4、然后选择到Configuration这个选项。

5、然后经常需要设置的为下面的Parameters的选项。

SpringBoot中,@Autowired和@Resource使用起来到底有什么区别

这个问题也有一段时间了,当初也就随手一写,直到最近还有网友在看,为了保证大家看的时候不会出现理解方面的问题,于2021-5-10编辑一次,希望能更加严谨一点,至少不会误导大家。

首先,这个问题有点不准确,这2个注解是使用Spring框架过程中常用的注解,而SpringMVC和SpringBoot等框架都是基于Spring的进阶框架,并没有对这2个注解的使用进行修改或者调整,所以,只讨论Spring框架如何处理这2个注解即可,而不是讨论在SpringBoot中的使用区别。

【结论】在绝大部分情况下,使用这2个注解的任何一个都可以实现自动装配,在使用方面是无感的。

如果要讨论区别,基本上就是2点:

所属不同:@Resource注解是javax包的;@Autowired是Spring声明的;装配机制不同:@Resource会优先byName来装配,即使名称不匹配,也会尝试byType来装配;@Autowired则是先查找匹配类型对象的数量,如果有且仅有1个,则直接装配,如果为0个,则无法装配,此时需要考虑该注解的required属性,默认是true,就会因为“必须装配却没有匹配类型的对象”而抛出异常,如果显式的设置为false,则不装配,保持被自动装配的属性为null值,如果匹配类型的对象超过1个,则会尝试byName,如果成功,则装配,如果失败,则抛出异常。

如果一定要说还有其它区别,可以是:

作用范围不同:@Resource用于对字段、Setter方法进行注解,@Autowired可用于构造方法、Setter方法和字段;当同一种类型的对象有多个时(例如声明的类型是接口,在Spring容器中有2个或多个实现类的对象),需要指定名称,@Resource可直接配置name属性来指定bean-name,而@Autowired需要配合@Qualifer注解,由@Qualifer注解来指定bean-name,当用于字段时,直接在字段的声明之前使用这2个注解,当用于Setter方法时,在方法的声明之前使用@Autowired,在方法的参数之前使用@Qualifer;

另外,还有很多关于使用@Autowired的细节问题,例如“是不是不建议使用了”、“到底应该怎么用”等等,所以,接下来主要讨论这些问题。

关于“是不是不建议使用了”,这种问题的主要原因应该是最近几年IntelliJIDEA越来越流行了,而许多版本的IntelliJIDEA对@Autowired的预判是有问题的!也就是说:IntelliJIDEA会在编码期实时预判是否存在可以装配的对象,如果它认为没有,就会报错,事实上,它的判断并不完全准确!

例如,尝试在Service组件中装配一个Mapper接口类型的字段时:

(截图来自IntelliJIDEA2020.1.4)

以上报错就是IntelliJIDEA预判错误导致的,如果使用的是Eclipse就不会有这样的问题,解决方案可以是:

在UserMapper接口上添加@Repository注解;将以上代码中的@Autowired配置为@Autowired(required=false),因为@Autowired默认是required=true,同时IntelliJIDEA认为没有可装配对象,所以报错,显式的配置为required=false之后,即使IntelliJIDEA认为没有可装配对象也不会报错了;将以上代码中的@Autowired改为@Resource。

再例如在使用SpringSecurity进行配置时也会有类似的问题,只不过这次它认为“存在多个匹配类型的对象”:

(截图来自IntelliJIDEA2020.1.4)

解决以上报错信息的方式可以是:

将声明的UserDetailsService接口类型改为你的UserDetailsServiceImpl实现类类型,例如privateUserDetailsServerImplservice;即可;将以上代码中的@Autowired改为@Resource。

由于许多类似问题都可以通过“将@Autowired改为@Resource”来解决,加上一些相关说法(详见下文),且某些片面的断章取义,导致网上还存在“使用@Resource取代@Autowired”、“以后不要再用@Autowired”的说法,而这些说法都是错误的,没有任何官方(开发工具的IntelliJIDEA,或框架官方Spring)说过这样的话!

首先,使用Spring实现自动装配时,有3种方式:

通过构造方法注入;通过Setter注入(即与字段属性匹配的set方法);通过字段注入;

基本示例参见下图:

以上图片来自Spring官方提供的资料,可以看到最后还附了个URL,是国外网友写的一篇主题为《whyfieldinjectionisevil》的讨论文章,有兴趣且有一定英语阅读能力的朋友可以自行上网查看全文,大意是“使用字段注入时可能导致NPE”!为什么会这样呢?假设你有如下代码:

如果你因为某种原因直接创建对象,即通过UserServiceservice=newUserService();来创建对象,其中的userRepository属性肯定是没有值的,后续使用这个service对象时,只要涉及调用userRepository就会出现NPE了!

既然UserService是一个组件,为什么还会直接创建对象呢?其实这也算是一个低概率的特殊情况,在彼此不太熟悉的协同工作中可能出现,例如你和我一起开发项目,我对你写的那部分代码不太了解……再就是测试使用时,也可能出现直接创建对象的情况……

如果将代码改为下面这样:

则刚才的问题就不存在了!因为现在的构造方法是需要参数的,你不给参数,就创建不了对象!如果能创建出对象,就肯定给了参数,则userRepository肯定有值,就不会出现NPE!当然,如果你一定要传个null进去就没办法了,Nozuonodiewhyyoutry?

所以,使用构造方法传递参数是一种强制依赖的做法,可以保证不会出现NPE,但是,如果参数太多会不会很奇怪?真的有必要把代码写得这么滴水不漏吗?这个就看你自己了!首先,是IntelliJIDEA并不建议你使用字段注入:

(截图来自IntelliJIDEA2020.1.4)

而Spring的观点,可参见下图:

可以看到,Spring是无所谓的,反正都能用(Springdoesn'tcare,canuseeither),当然,也列举了使用构造方法注入和使用Setter注入的区别(虽然我在前面都是写的字段注入,在NPE问题上,字段注入和Setter注入是一样的)。

既然Spring都无所谓了,我们为什么还要纠结注入方式呢?还是那句话,只要你能保证不出错,怎么都行!可能95%以上的Java从业者不是在写大厂的大型项目,合格的程序员也不会乱写代码,由Setter或字段注入导致NPE的概率本来就极低,不一定需要为了“保证极端情况下也不出错”而刻意的把代码调整为构造方法注入,只要注意规避这个问题即可!

另外,我在上面的代码演示中,在构造方法上加了@Autowired注解,在这里解释一下:

如果类中只存在默认构造方法(无论是你显式的添加的,还是根本不写,由编译器添加的),则无需@Autowired注解,Spring会自动调用,当然,加了也不会出错;如果类中只存在唯一的构造方法,Spring会自动调用,且会自动从Spring容器中找对象装配为调用构造方法的参数,这种情况也是不需要添加@Autowired注解的,加了也不会出错;如果类中存在多个构造方法,且都没有添加@Autowired注解时,当存在无参数构造方法时,Spring会自动调用无参数构造方法,如果你想要Spring调用另外某一个构造方法,就在那个构造方法上添加@Autowired注解;如果类中存在多个构造方法,且超过1个构造方法上都添加了@Autowired注解……你别作,你不需要知道Spring怎么处理,你只要把@Autowired删得只有1个了,就肯定没问题!

所以,从道理上来说,应该推荐显式的为某1个构造方法添加@Autowired注解,哪怕是不需要添加也能用,因为这样会保证多构造方法的情况下代码更加直观,增加代码的可读性,但是,从实际工作出发,可能就变成了“有啥好加的?这点道理都不懂还上什么班?”……大家都懒得加了,所以,又不是什么很难懂的原理,加不加就自行把握吧。

最后,再总结一下使用原则:

@Autowired和@Resource在使用时可以不纠结它们的区别,使用它们的目的就是为了装配对象,只要能装得上,装的是对的,无所谓使用哪个?一定要区分选取,先保证“在同一个项目中使用同一个”,不要一个类使用@Autowired,另一个类又使用@Resource,然后,我个人建议使用@Autowired,原因嘛,很简单,你既然用Spring框架,就用它带的注解呗;关于@Autowired的使用方式,不怕麻烦就都使用构造方法注入,且显式的添加@Autowired,如果怕麻烦,只要不出错,就随意吧。

Spring官方也考虑到了网友关于@Resource或相关注解的问题,因为没什么需要特别解释的了,就直接贴图好了,大家自行查阅,以下图片仍是来自Spring官方资料:

最后,近期因为工作的关系看了不少Spring的官方资料,包括官方的Spring学习教程,有些感慨,给我的感觉,Spring对外提倡实用主义,极少和你讲理论,源码什么的更是少得可怜,这也和面向对象的思想保持一致,人家都帮你做好了,你好好用就行了,不必关心实现细节,希望大家也能这样!现在IT行业真的被一些大厂带节奏了,网上各种吸引眼球的XX源码解析、XX底层原理、XX加载过程分析、XX算法、大厂案例、大厂面试题……很多时候真的想喷一句“你咋不从操作系统开始做软件研发呢”……真的,绝大部分Java从业者一辈子都进不了大厂,也接触不到超过20台以上服务器才能扛得住的项目,除非是为了应付面试,你甚至不需要知道i++和++i的区别,如果只是自己写代码自己用,你也不需要知道private和public的区别……如果你只想开自己的私家车,不想修车也不想造车,除了吹牛,你都不需要知道发动机的型号……多掌握实用技术,多积累解决问题的经验,原理什么的能不管就不要管,当熟练到一定程度后,再考虑要不要深入了解原理。

好了,就这么多,如果有错别字,大家将就一下吧(可编辑次数有限),如果有觉得不对的地方,欢迎留言讨论。

spring中普通类调用service类怎么调用

1、如果你想用@autowired,那么这个类本身也应该是在spring的管理下的,即你的UserLogUtil也要标注为一个component(或Service),这样spring才知道要注入依赖;

2、或者,不标注为component的话,此时不能通过@autowired来注入依赖,只能通过ApplicationContext来取得标注为Service的类:

UserLogServiceservice=ApplicationContext.getBean(UserLogService.class);

如果你还想了解更多这方面的信息,记得收藏关注本站。

Spring Boot Autowired属性注入问题