Pro e contro di AppSettings vs applicationSettings (.NET app.config / Web.config)

Quando sviluppiamo un'applicazione .NET Windows Forms abbiamo la scelta tra quei App.configtag per memorizzare i nostri valori di configurazione. Qual è il migliore?

<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>

La base <appSettings>è più facile da gestire: basta dare uno schiaffo in una <add key="...." value="..." />voce e il gioco è fatto.

Il rovescio della medaglia è: non esiste un controllo del tipo, ad esempio non si può presumere in sicurezza il proprio numero che si desidera configurare, in realtà esiste un numero - qualcuno potrebbe inserire una stringa in quell'impostazione ..... basta accedervi come ConfigurationManager["(key)"]e poi è su a te sapere con cosa hai a che fare.

Inoltre, nel tempo, <appSettings>possono diventare piuttosto contorti e disordinati, se molte parti della tua app iniziano a inserire elementi (ricordi il vecchio file windows.ini? :-)).

Se puoi, preferirei e consiglierei di usare le tue sezioni di configurazione - con .NET 2.0, è diventato davvero abbastanza facile, In questo modo puoi:

• a) Definisci le tue impostazioni di configurazione nel codice e falle scriverle e verificarle
• b) È possibile separare in modo pulito le VOSTRE impostazioni da quelle di tutti gli altri. E puoi anche riutilizzare il tuo codice di configurazione!

C'è una serie di ottimi articoli su di te per demistificare il sistema di configurazione .NET 2.0 su CodeProject:

1. Svelare i misteri della configurazione di .NET 2.0

2. Decodifica i misteri della configurazione di .NET 2.0

3. Craccare i misteri della configurazione di .NET 2.0

Altamente raccomandato! Jon Rista ha fatto un ottimo lavoro spiegando il sistema di configurazione in .NET 2.0.

Le impostazioni dell'applicazione possono essere controllate da un designer (di solito esiste un file Settings.settings per impostazione predefinita), quindi è più facile modificarlo e puoi accedervi a livello di codice attraverso la classe Settings dove appaiono come una proprietà fortemente tipizzata. Puoi anche avere impostazioni a livello di applicazione e utente, nonché impostazioni predefinite per il rollback.

Questo è disponibile da .NET 2.0 in poi e depreca l'altro modo di farlo (per quanto ne so).

Maggiori dettagli sono disponibili su: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

Ho usato un modello che ho trovato qualche tempo fa in cui usi tag xml di base ma racchiudi le impostazioni in una classe di configurazione statica. Quindi - un'app fai-da-te.

Modello di configurazione statica DotNetPearls

Se lo fai in questo modo puoi:

• usa diversi set di valori di configurazione per diversi ambienti (sviluppo, test, prod)
• fornire impostazioni predefinite ragionevoli per ciascuna impostazione
• controlla come i valori vengono definiti e istanziati

È noioso da impostare ma funziona bene, nasconde riferimenti ai nomi delle chiavi ed è fortemente tipizzato. Questo tipo di pattern funziona bene per le configurazioni che non sono state modificate dall'applicazione, anche se probabilmente si potrebbe anche lavorare a supporto delle modifiche.

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 di configurazione:

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
    }

Per comprendere i pro e i contro delle impostazioni in app.config, ti suggerisco di esaminare i dettagli tecnici di entrambi. Ho incluso collegamenti in cui è possibile trovare il codice sorgente per la gestione, descrivendo ulteriori dettagli tecnici di seguito.

Consentitemi di riassumere brevemente ciò che ho riconosciuto quando ho lavorato con loro ( nota: lo stesso vale per il web.configfile di un sito Web / applicazione Web):

Settaggi applicazione in .NET
(fare clic sopra per visualizzare il codice sorgente e i dettagli tecnici)

Professionisti

• Consentono di archiviare dati digitati, inclusi i tipi di oggetto (tramite serializeAsproprietà)

• Hanno un ambito utente e applicazione, che consente di memorizzare i valori predefiniti

• Sono supportati nella sezione di configurazione di Visual Studio

• Stringhe lunghe e / o dati con caratteri speciali sono molto ben supportati (ad esempio stringhe JSON incorporate contenenti virgolette doppie)

Contro

• Le impostazioni dell'utente sono memorizzate in una posizione diversa nel profilo utente (con un percorso criptico), può essere difficile da ripulire

• Le impostazioni dell'ambito dell'applicazione sono di sola lettura durante il runtime dell'applicazione (solo le impostazioni dell'ambito utente possono essere modificate durante il runtime)

• Codice dei metodi di lettura / scrittura creato dal designer delle impostazioni di Visual Studio, non fornito direttamente da strumenti di terze parti (vedere il collegamento sopra per una soluzione alternativa)

Aggiornamento AppSettings in .NET : AppSettings in .NET Core
(fare clic sopra per visualizzare il codice sorgente e i dettagli tecnici)

Professionisti

• Sono "leggeri", cioè facili da maneggiare

• Accesso in lettura e scrittura durante il runtime dell'applicazione

• Possono essere facilmente modificati dagli amministratori in Gestione
  Internet Information Services (IIS)
  ^{(Visualizzazione funzionalità -> Impostazioni applicazione, si noti che il nome dell'icona è fuorviante poiché può gestire solo le impostazioni delle applicazioni e non quelle delle applicazioni)}

Contro

• Supporta solo dati stringa; la lunghezza della stringa e i caratteri speciali sono limitati

• Non hanno un ambito utente

• Non supportano i valori predefiniti

• Non sono supportati direttamente nella sezione di configurazione di Visual Studio

Mi piace lavorare con la versione più semplice per archiviare e accedere a singoli valori.

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

Ho scritto una classe di utilità per accedere ai valori in modo typesafe che consente valori predefiniti. Se non vengono forniti valori predefiniti, vengono forniti utili messaggi di eccezione.

Puoi vedere / scaricare la classe qui:

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