亲宝软件园·资讯

展开

【玩转SpringBoot】配置文件yml的正确打开姿势

编程新说(李新杰) 人气:1


序言


在很久以前,Spring的配置文件是基于XML的。它的名字就是applicationContext.xml,没错,就只有这一个xml文件。

它里面配置了所有的东西。但是数据库信息通常会单独拿出来,放入一个properties文件,通常叫db.properties。

后来觉着一个xml里的东西实在太多了,就按功能拆分成几个独立的xml。

spring-dao.xml是dao层,spring-service.xml是service层,spring-tx.xml是事务相关,dispatcher-servlet.xml是web相关。

这么多的xml怎么办呢?很简单,就是在applicationContext.xml里都引用它们即可。

随着JDK在1.5加入了对注解的支持,Spring也慢慢的向注解转化。直至后来一个xml都不剩,全部变为注解,连web.xml都没有了。

是xml不行了,还是注解太牛X了,其实它们是等价的,连官网上都说它们一摸一样,故而不做推荐,让用户根据实际情况自己选择。

不过,最终历史还是抛弃了XML,肯定是多方面的原因,可能如下:

1)人们厌倦了XML,出现审美疲劳

2)试用了注解很爽,一发不可收拾

3)注解代表着先进的生产力,极大提升了效率

4)XML拖沓累赘,注解清爽干脆

5)大家都觉得使用注解比使用XML更牛B。

于是乎,一个辉煌的新时代碾压了一个曾经辉煌的曾经的新时代。

呵呵,历史是什么,就是个车轮。一切皆可碾压。

总之,既有实际实践问题,又有思想意识问题,说不清,道不明。

随着SpringBoot的横空出世,配置文件的概念又发了变化。

SpringBoot强调自动配置(也叫自动装配),所以配置对它来说很重要。

配置文件属于配置的一部分,自然也变得非常重要,于是yml就应势站了起来。

yml从未像现在这样流行,成了新时代的网红。


yml配置文件的格式


每种新事物的流行,总会有它比旧事物更好的地方。

作为Java界配置文件鼻祖,非properties文件莫属,它里面的格式就不用再举例了吧。

它是一维非结构化的,一行一个,写多了容易乱。

而yml文件是二维结构化的,有严格的缩进,结果就是层次分明,非常清晰。

而且,常用的配置都能得到支持,这就是它的优势,所以就流行起来了。

一、List配置格式,如下图01:

 

二、Map配置格式,如下图02:

 

三、List套List格式,如下图03:

 

四、List套Map格式,如下图04:

 

五、Map套Map格式,如下图05:

 

六、Map套List格式,如下图06:

 

虽然有些嵌套可能并不适用,这里只是说明yml支持这样的嵌套,如果愿意的话,嵌套层次还可以更深。


yml配置文件内容的存储


大家都知道SpringBoot是由Spring发展而来的,Spring里是有Environment这个概念的。

所有的环境变量、系统属性、配置文件内容都会放进去。

通常的配置项都是一些key=value,就和properties文件是一样的。所以Environment底层也是这样实现的。

但到了SpringBoot中,配置文件变为yml了,是二维结构化的,根本没有办法直接用key=value这种形式表示。

但是,yml配置文件的内容还必须要放入到Environment中去。那怎么办呢?看来二者必须要修改其一了。

由于Spring已经很多年了,它里面的很多概念都已经固化下来了,包括Environment内部的结构与实现。

因此,最终选择yml去适配Environment,把二维结构化变为一维非结构化,即把有层次的变为简单的key=value形式。

这在编程里有一个专门的术语,叫扁平化。其实人员管理里面也有扁平化。

具体规则也非常简单,把父子关系用点号(.)表示,把列表索引用中括号([])表示。

把刚刚的配置内容输出来看看,如下图070809:


这样就完成了扁平化,就可以存入到Environment中去了。

等号(=)前面的就是key,后面的就是值。


直接粗暴的使用yml配置文件内容


由于yml配置文件内容最终会进入Environment中,所以就等于直接粗暴的从Environment中读取值。

此时,key必须要写成上面那样子,否则取不到值。

一、直接从Environment中读取,如下图10:

 

结果输出如下图11:

 

二、使用@Value注解,如下图12:

 

结果输出如下图13:

 

这就是简单粗暴的方式,除了看上去不美观之外,还把yml的结构化特征给丢失了。

其实,还有一个比较严重的问题,就是只能获取到最终key对应的单个值,如果想获取一个List或Map作为返回值,是不行的。


优雅的使用yml配置文件内容


key=value这种形式其实就是个Map,而Map其实和Java Bean差的并不多,只不过Bean中是属性名和属性值罢了。

Map套Map就等于Bean套Bean,这样无论结构形式还是语义表达都能很完美的映射过来。

且Bean是强类型的,属性名和属性类型一目了然,比Map强多了。

所以yml配置文件里的内容可以映射为Java里的Bean,这就是SpringBoot推荐的优雅的使用方式。

这里的核心问题就是,yml里的配置项要和Bean中的属性名称和类型对应好,不然会出问题。

下面请看一个示例,自己瞎编了一个游泳比赛的得分和奖品的配置。

含有一等奖、二等奖、三等奖的得分区间,和它们分别对应的奖品名称和数量。

如下图14:

 

可以看到scores对应的是一个列表,它有三个元素,每个元素都有level、lowBound、highBound三个属性。

awards对应一个Map,它有三个key,分别是level1、level2、level3,每个key对应的值又是一个列表。

且列表都含有两个元素,且每个元素都有name、count两个属性。

如果这个明白了,下面请看它对应的Bean,如下图15:

 

Score和Award是两个静态内部类。一个有三个属性,一个有两个属性。

ScoreProperties类中有两个属性,一个是scores,类型是List<Score>。

一个是awards,类型是Map<String, List<Award>>。

可以看出,它们和yml的结构是完全吻合的。没有难度吧。

为了使它用起来更优雅,SpringBoot定义了两个注解来助它一臂之力。

首先,在Bean上标上@ConfigurationProperties,表示它是一个“配置属性”。

如下图16:

 

其次,在另一个类上使用@EnableConfigurationProperties注解将其引入。

如下图17:

 

经过这两步,这个“配置属性”类就已经被注册到容器里了,就变成一个普通的bean了。

这样就可以把它注入到需要的地方,如下图18:

 

使用的是构造方法注入,并输出一下它的值,看看和yml中配置的是否一样。

结果如下图19:

 

可以看到,完全没有问题。这就是SpringBoot推荐的方式。

SpringBoot框架内部的源码都是这样用的。

既然“配置属性”类最后注册了bean定义,那可不可用常规的bean定义注册方式呢?

试试就知道了,如下图20:

 

可以看出,这里使用的@Component注解。

这样的话,就不再需要另一个注解引入了,把它注释掉,如下图21:

 

其它的都保持不变。然后进行测试,发现完全可以。

不过还是推荐使用SpringBoot指定的方式,因为SpringBoot可以对这种方式进行特殊的优化处理。

比如使用@Validated进行验证。还可以把@NestedConfigurationProperty注解标到嵌套的字段上。

这样不会影响属性值的绑定,但是可以让SpringBoot给你在IDE中进行智能提示。

不然在没有源码的情况下,根本不知道“配置属性”类的结构以及属性名和属性类型。

>>> 热门文章集锦 <<<

 

毕业10年,我有话说

【面试】我是如何面试别人List相关知识的,深度有点长文

我是如何在毕业不久只用1年就升为开发组长的

爸爸又给Spring MVC生了个弟弟叫Spring WebFlux

【面试】我是如何在面试别人Spring事务时“套路”对方的

【面试】Spring事务面试考点吐血整理(建议珍藏)

【面试】我是如何在面试别人Redis相关知识时“软怼”他的

【面试】吃透了这些Redis知识点,面试官一定觉得你很NB(干货 | 建议珍藏)

【面试】如果你这样回答“什么是线程安全”,面试官都会对你刮目相看(建议珍藏)

【面试】迄今为止把同步/异步/阻塞/非阻塞/BIO/NIO/AIO讲的这么清楚的好文章(快快珍藏)

【面试】一篇文章帮你彻底搞清楚“I/O多路复用”和“异步I/O”的前世今生(深度好文,建议珍藏)

【面试】如果把线程当作一个人来对待,所有问题都瞬间明白了

Java多线程通关———基础知识挑战

品Spring:帝国的基石

 

>>> 品Spring系列文章 <<<

 

品Spring:帝国的基石

品Spring:bean定义上梁山

品Spring:实现bean定义时采用的“先进生产力”

品Spring:注解终于“成功上位”

品Spring:能工巧匠们对注解的“加持”

品Spring:SpringBoot和Spring到底有没有本质的不同?

品Spring:负责bean定义注册的两个“排头兵”

品Spring:SpringBoot轻松取胜bean定义注册的“第一阶段”

品Spring:SpringBoot发起bean定义注册的“二次攻坚战”

品Spring:注解之王@Configuration和它的一众“小弟们”

品Spring:bean工厂后处理器的调用规则

品Spring:详细解说bean后处理器

品Spring:对@PostConstruct和@PreDestroy注解的处理方法

品Spring:对@Resource注解的处理方法

品Spring:对@Autowired和@Value注解的处理方法

品Spring:真没想到,三十步才能完成一个bean实例的创建

品Spring:关于@Scheduled定时任务的思考与探索,结果尴尬了

 

作者是工作超过10年的码农,现在任架构师。喜欢研究技术,崇尚简单快乐。追求以通俗易懂的语言解说技术,希望所有的读者都能看懂并记住。下面是公众号的二维码,欢迎关注!


 

加载全部内容

相关教程
猜你喜欢
用户评论