用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

假设在项目的根目录有这样一个json文件, 在ASP.NET Core项目里我们可以使用IConfigurationRoot来使用该json文件作为配置文件, 而IConfigurationRoot是使用ConfigurationBuilder来创建的:

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

可以看到ConfigurationBuilder加载了firstConfig.json文件, 使用的是AddJsonFile这个扩展方法. 调用builder的Build方法会得到一个IConfigurationRoot的实例, 它实现了IConfiguration接口, 随后我们便可以通过遍历它的键值对.

其中json文件里的结构数据都最为键值对被扁平化到IConfiguration里了, 我们可以通过它的key找到对应的值:

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

像childkey1这种带层次结构的值可以使用冒号 作为层次分隔符.

配置文件总会包含这种多层结构的, 更好的办法是把类似的配置进行分组获取, 可以使用IConfiguration的GetSection()方法来获取局部的配置:

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

 

当有多个配置文件的时候, 配置数据的加载和它们在程序中指定的顺序是一样的, 如果多个文件都有同一个键的话, 那么最后加载的值将会覆盖先前加载的值.

下面是另一个配置文件:

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

在firstConfig后加载secondConfig:

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

最后key1的值是后加载的secondConfig里面的值.

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

当然了, 如果firstConfig里面有而secondConfig却没有的键, 它的值肯定来自firstConfig.

 

配置提供商

配置数据可以来自多种数据源, 它们可能是不同格式的.

ASP.NET Core 默认支持从下列方式获得配置:

文件格式(INI, JSON, XML)

命令行参数

环境变量

内存中的.NET对象

未加密的Secret管理存储

加密的用户存储, 例如Azure秘钥库

自定义的提供商

这些东西还是看官方文档吧, 本文使用JSON格式的就够用了.

 

强类型的配置

ASP.NET Core允许把配置数据映射到一个对象类上面.

针对上面的firstConfig.json文件, 我们创建以下这个类:

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

然后调用IConfiguration的Bind扩展方法来把键值对集合对值映射到这个强类型对POCO实例里:

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

 

在标准的ASP.NET Core 2.0的项目模版里, 加载配置文件的步骤被封装了, 默认或加载appSettings.json 以及 appSettings.{环境}.json.

我记得是封装在这里了:

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

我把firstConfig.json改名为appSettings.json.

然后在Startup里面可以获得IConfiguration:

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

用ASP.NET Core 2.0 建立规范的 REST API -- 预备知识 (2) + 准备项目

从打印结果可以看到, 加载的不只是appSettings里面的内容, 还有系统环境变量的值.

这种情况下, 使用IServiceCollectionConfigure扩展方法可以把配置映射到指定的类上面:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wppdgg.html