.NET 5: Configuration Provider
Você sabia que em uma aplicação .NET, por padrão, temos mais de um provider de configuração?
Você sabe dizer quais são esses providers, e sua ordem de “prioridade”?
Você sabia que é possível customizar, não apenas a ordem destes providers, como também é possível incluir novos providers dando a suas aplicações novas possibilidades?
Antes de falarmos sobre como modificar os providers, vamos falar sobre os providers padrões da nossa aplicação.
Para este exemplo estamos utilizando uma aplicação tipo WebAPI MVC sem quaisquer modificações.
Em nosso Startup.cs foi adicionada uma referência para o IConfiguration, ao debugar a aplicação é possível notar que temos quatro providers sendo utilizados.
O funcionamento do configuration é semelhante ao do padrão Chain of Responsability, caso uma configuração não seja encontrada no provider de maior prioridade os demais serão testados um a um, ou se olharmos por um outro prisma, o provider de maior relevância tem o ‘poder’ de sobreescrever uma determinada propriedade.
Imaginem o seguinte cenário:
Temos uma aplicação que faz uso de um mecanismo de cache e o tempo de expiração do cache é parametrizado através da chave “TTLCache”
Propositalmente vou configurar a mesma variável como sendo uma variável de ambiente, e também no appsettings.json e no appsettings.Development.json.
Ao consultar a chave “TTLCache” conforme esperado o numero retornado é 30
Imagine agora o cenário onde você faz uso de um banco de dados, e por motivos óbvios você não quer expor as credenciais de acesso ao banco de dados em seu repositório que é aberto.
É possível fazer uso dos secrets, ele funciona criando um id e associando este id ao seu projeto, e então um arquivo de configuração é criado em uma pasta onde apenas o seu usuário tem acesso.
dotnet user-secrets init
dotnet user-secrets set “ConnectionStrings:DefaultConnection” “maquina do fructuoso”
Notem que a chave de configuração ConnectionStrings:DefaultConnection existe apenas no secret.
Ao debugar a aplicação o valor é retornado normalmente, porém essa chave não subirá para o repositório.
Obs.: O provider do secret é adicionado automaticamente a partir do momento que executamos o comando “dotnet user-secrets init”
Por fim, como eu disse no início é possível modificar a ordem de prioridade dos providers, ou até mesmo fazer uso de novos providers.
Neste exemplo vamos criar um fructuoso.ini e vamos desconsiderar o uso do arquivo appsettings.json. (não que seja “normal” fazer isso, estou fazendo apenas para demonstrar que é possível e como fazer)
Em resumo existem diversas formas de armazenar as configurações da sua aplicação, na minha experiência o mais usual é utilizar o appsettings para variaveis da sua aplicação que não mudam de acordo com o ambiente, appsettings.Development (e suas variações) para variáveis da sua aplicação que mudam de acordo com o ambiente, environment variaveis pra variáveis que são compartilhadas por todas as aplicações que estão rodando em um mesmo ambiente, e o secret para as variáveis que você não quer que estejam expostas em seu repositório (principalmente quando ele é público)
Referências:
