Prós e contras de AppSettings vs applicationSettings (.NET app.config / Web.config)

Ao desenvolver um aplicativo .NET Windows Forms, temos a opção entre essas App.configtags para armazenar nossos valores de configuração. Qual é o melhor?

<configuration>

  <!-- Choice 1 -->
  <appSettings>
    <add key="RequestTimeoutInMilliseconds" value="10000"/>
  </appSettings>

  <!-- Choice 2 -->
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" >
        <section name="Project1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <Project1.Properties.Settings>
      <setting name="TABLEA" serializeAs="String">
        <value>TABLEA</value>
      </setting>
    </Project1.Properties.Settings>
  </applicationSettings>

</configuration>

O básico <appSettings>é mais fácil de lidar - basta clicar em uma <add key="...." value="..." />entrada e pronto.

A desvantagem é: não há verificação de tipo, por exemplo, você não pode assumir com segurança o seu número que você deseja configurar, realmente existe um número - alguém poderia colocar uma string nessa configuração ... você simplesmente acessa-a ConfigurationManager["(key)"]e então acaba para você saber com o que está lidando.

Além disso, com o tempo, <appSettings>pode ficar um pouco complicado e bagunçado, se várias partes do seu aplicativo começarem a colocar coisas lá (lembre-se do antigo arquivo windows.ini? :-)).

Se você puder, eu preferiria e recomendaria o uso de suas próprias seções de configuração - com o .NET 2.0, ficou realmente muito fácil. Dessa forma, você pode:

• a) Defina suas configurações no código e faça com que sejam seguras e verificadas
• b) Você pode separar SUAS configurações de todas as outras pessoas. E você também pode reutilizar seu código de configuração!

Há uma série de artigos muito bons sobre você para desmistificar o sistema de configuração do .NET 2.0 no CodeProject:

1. Desvendando os mistérios da configuração do .NET 2.0

2. Decodificando os mistérios da configuração do .NET 2.0

3. Quebrando os mistérios da configuração do .NET 2.0

Altamente recomendado! Jon Rista fez um ótimo trabalho ao explicar o sistema de configuração no .NET 2.0.

As configurações do aplicativo podem ser controladas a partir de um designer (geralmente, por padrão, há um arquivo Settings.settings), portanto é mais fácil modificar e você pode acessá-las programaticamente através da classe Settings, onde elas aparecem como uma propriedade fortemente tipada. Você também pode ter configurações de nível de aplicativo e usuário, bem como configurações padrão para reversão.

Isso está disponível no .NET 2.0 em diante e obsoleta a outra maneira de fazê-lo (tanto quanto eu sei).

Mais detalhes são fornecidos em: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

Eu tenho usado um padrão que encontrei há algum tempo, em que você usa tags xml básicas, mas quebra as configurações em uma classe de configuração estática. Então - um App.Settings DIY.

Padrão de configuração estática do DotNetPearls

Se você fizer dessa maneira, poderá:

• use conjuntos diferentes de valores de configuração para diferentes ambientes (dev, test, prod)
• fornecer padrões sensíveis para cada configuração
• controlar como os valores são definidos e instanciados

É tedioso de configurar, mas tem um bom desempenho, oculta referências a nomes de chaves e é fortemente digitado. Esse tipo de padrão funciona bem para configurações que não são alteradas pelo aplicativo, embora você provavelmente também possa trabalhar no suporte a alterações.

Config:

<add key="machineName" value="Prod" />
<add key="anotherMachineName" value="Test" />
<add key="EnvTypeDefault" value="Dev" />

<add key="RootURLProd" value="http://domain.com/app/" />
<add key="RootURLTest" value="http://test.domain.com/app/" />
<add key="RootURLDev" value="http://localhost/app/" />

<add key="HumanReadableEnvTypeProd" value="" />
<add key="HumanReadableEnvTypeTest" value="Test Mode" />
<add key="HumanReadableEnvTypeDev" value="Development Mode" />

Classe de configuração:

using System;
using System.Collections.Generic;
using System.Web;
using WebConfig = System.Web.Configuration.WebConfigurationManager;

    public static class Config
    {
        #region Properties

        public static string EnvironmentType { get; private set; }

        public static Uri RootURL { get; private set; }

        public static string HumanReadableEnvType { get; private set; }

        #endregion

        #region CTOR

        /// <summary>
        /// Initializes all settings when the app spins up
        /// </summary>
        static Config()
        {
            // Init all settings here to prevent repeated NameValueCollection lookups
            // Can increase performance on high volume apps

            EnvironmentType =
                WebConfig.AppSettings[System.Environment.MachineName] ??
                "Dev";

            RootURL =
                new Uri(WebConfig.AppSettings["RootURL" + EnvironmentType]);

            HumanReadableEnvType =
                WebConfig.AppSettings["HumanReadableEnvType" + Config.EnvironmentType] ??
                string.Empty;
        }

        #endregion
    }

Para entender os prós e os contras das configurações no app.config, sugiro que você analise os detalhes técnicos de ambos. Incluí links onde você pode encontrar o código-fonte para manipulação, descrevendo mais detalhes técnicos abaixo.

Deixe-me resumir brevemente o que reconheci quando trabalhei com eles ( nota: o mesmo se aplica ao web.configarquivo de um site / aplicativo da web):

applicationSettings no .NET
(clique acima para visualizar o código fonte e os detalhes técnicos)

Prós

• Eles permitem armazenar dados digitados, incluindo tipos de objetos (via serializeAspropriedade)

• Eles têm um escopo de usuário e aplicativo, permitindo armazenar valores padrão

• Eles são suportados na seção de configuração do Visual Studio

• Sequências longas e / ou dados com caracteres especiais são muito bem suportados (por exemplo, sequências JSON incorporadas que contêm aspas duplas)

Contras

• As configurações do usuário são armazenadas em um local diferente no perfil do usuário (com um caminho enigmático), pode ser difícil de limpar

• As configurações do escopo do aplicativo são somente leitura durante o tempo de execução do aplicativo (somente as configurações do escopo do usuário podem ser alteradas durante o tempo de execução)

• Código de métodos de leitura / gravação criado pelo designer de configurações do Visual Studio, não fornecido diretamente por ferramentas de terceiros (consulte o link acima para obter uma solução alternativa)

AppSettings no .NET
Update: AppSettings no .NET Core
(clique acima para visualizar o código-fonte e detalhes técnicos)

Prós

• São "leves", ou seja, fáceis de manusear

• Acesso de leitura e gravação durante o tempo de execução do aplicativo

• Eles podem ser editados facilmente pelos Administradores no
  Gerenciador dos Serviços de Informações da Internet (IIS)
  ^{(Exibição de recursos -> Configurações do aplicativo, observe que o nome do ícone é enganoso, pois ele pode lidar apenas com AppSettings e não ApplicationSettings)}

Contras

• Suporte apenas dados de string; comprimento da string e caracteres especiais são limitados

• Eles não têm um escopo de usuário

• Eles não suportam valores padrão

• Não são suportados diretamente na seção de configuração do Visual Studio

Gosto de trabalhar com a versão mais simples para armazenar e acessar valores únicos.

<appSettings>
    <add key="MyConfigKey" value="true"/>
</appSettings>

Eu escrevi uma classe de utilitário para acessar valores de uma maneira segura que permite valores padrão. Se os padrões não forem fornecidos, serão fornecidas mensagens de exceção úteis.

Você pode ver / baixar a turma aqui:

http://www.drewnoakes.com/code/util/app-settings-util/