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


166

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>

No código de exemplo do MS, eles usam appSettings msdn.microsoft.com/en-us/library/… isso acho confuso :(
Hunt

Encontrado este artigo codeproject.com/KB/files/… , parece implicar que appSettings são para / e os applicationSettings são apenas para leitura.
Caça

Outro artigo que é relevante stackoverflow.com/questions/453161/…
Hunt

Observe que o mesmo se aplica ao web.config, então eu adicionei a tag web.config a esta pergunta.
Matt

Respostas:


151

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.


2
Acho que applicationSettings é mais fácil de adicionar, editar e remover configurações, além de você não precisar escrever uma linha de código, além de serem do tipo seguro, além de poder defini-las para usuário ou aplicativo, porque você pode simplesmente usar a guia Configurações nas configurações do seu projeto. propriedades no VS.
Markmnl

20

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


14

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
    }

11

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



9

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/


3
+1, é mais simples, especialmente se você tiver várias montagens (as configurações normalmente têm uma seção por montagem). Eu tenho uma classe auxiliar semelhante. Atualmente, sua classe espera que o arquivo de configuração use seqüências sensíveis à cultura, o que não é uma coisa boa - por exemplo, deve ser "Double.TryParse (s, NumberStyles.Any, CultureInfo.InvariantCulture, resultado)" em vez de "Double.TryParse ( s, resultado) ". Também para nitpick, as diretrizes de codificação da Microsoft recomendam GetInt32, GetInt16, GetBoolean em vez de GetInt, GetShort, GetBool.
218 Joe Joe

Tudo bem, mas não responde à pergunta sobre os prós e contras do AppSettings.
6188 Matt

@ Matt, o profissional é que é mais simples. O golpe é que é mais simples. Se você precisar apenas de alguns valores literais (bools, ints, string, etc), essa abordagem dará o máximo de retorno. Se você precisar de dados estruturados, separação de namespace, validação / conclusão suportada por XSD etc., uma seção personalizada poderá ser mais adequada. Outra opção é ignorar o App.configarquivo completamente e usar seu próprio arquivo de configuração. Muitas bibliotecas fazem isso. NLog vem à mente.
Drew Noakes

@DrewNoakes - eu concordo com você. Obrigado pelo esclarecimento.
Matt
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.