Avantages et inconvénients d'AppSettings par rapport à applicationSettings (.NET app.config / Web.config)

Lors du développement d'une application Windows Forms .NET, nous avons le choix entre ces App.configbalises pour stocker nos valeurs de configuration. Quel est le meilleur?

<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>est plus facile à gérer - il suffit de frapper une <add key="...." value="..." />entrée et le tour est joué.

L'inconvénient est: il n'y a pas de vérification de type, par exemple, vous ne pouvez pas supposer en toute sécurité votre numéro que vous vouliez configurer il y a vraiment un nombre - quelqu'un pourrait mettre une chaîne dans ce paramètre ..... vous y accédez simplement au fur ConfigurationManager["(key)"]et à mesure à vous de savoir à quoi vous avez affaire.

De plus, avec le temps, le <appSettings>peut devenir assez alambiqué et désordonné, si de nombreuses parties de votre application commencent à y mettre des éléments (vous vous souvenez de l'ancien fichier windows.ini? :-)).

Si vous le pouvez, je préférerais et recommanderais d'utiliser vos propres sections de configuration - avec .NET 2.0, c'est vraiment devenu assez facile, de cette façon, vous pouvez:

• a) Définissez vos paramètres de configuration dans le code et faites-les vérifier et vérifier leur type
• b) Vous pouvez séparer proprement VOS paramètres de ceux de tous les autres. Et vous pouvez également réutiliser votre code de configuration!

Il existe une série de très bons articles sur vous pour démystifier le système de configuration .NET 2.0 sur CodeProject:

1. Découvrir les mystères de la configuration .NET 2.0

2. Décoder les mystères de la configuration .NET 2.0

3. Briser les mystères de la configuration .NET 2.0

Hautement recommandé! Jon Rista a fait un excellent travail en expliquant le système de configuration dans .NET 2.0.

Les paramètres d'application peuvent être contrôlés à partir d'un concepteur (il existe généralement un fichier Settings.settings par défaut), il est donc plus facile à modifier et vous pouvez y accéder par programme via la classe Settings où ils apparaissent comme une propriété fortement typée. Vous pouvez également avoir des paramètres de niveau application et utilisateur, ainsi que des paramètres par défaut pour la restauration.

Ceci est disponible à partir de .NET 2.0 et rend obsolète l'autre façon de le faire (pour autant que je sache).

Plus de détails sont donnés sur: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

J'ai utilisé un modèle que j'ai trouvé il y a quelque temps dans lequel vous utilisez des balises XML de base mais enveloppez les paramètres dans une classe de configuration statique. Donc - une application de bricolage.

Modèle de configuration statique DotNetPearls

Si vous procédez ainsi, vous pouvez:

• utiliser différents ensembles de valeurs de configuration pour différents environnements (dev, test, prod)
• fournir des valeurs par défaut raisonnables pour chaque paramètre
• contrôler la manière dont les valeurs sont définies et instanciées

Il est fastidieux à configurer mais fonctionne bien, masque les références aux noms de clé et est fortement typé. Ce type de modèle fonctionne bien pour la configuration qui n'est pas modifiée par l'application, bien que vous puissiez probablement également travailler pour la prise en charge des modifications.

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

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
    }

Pour comprendre les avantages et les inconvénients des paramètres dans le app.config, je vous suggère de vous pencher sur les détails techniques des deux. J'ai inclus des liens où vous pouvez trouver le code source pour la manipulation, décrivant plus de détails techniques ci-dessous.

Permettez-moi de résumer brièvement ce que j'ai reconnu lorsque j'ai travaillé avec eux ( note: il en va de même pour le web.configfichier d'un site Web / application Web):

applicationSettings dans .NET
(cliquez ci-dessus pour afficher le code source et les détails techniques)

Avantages

• Ils permettent de stocker des données typées, y compris des types d'objets (via serializeAspropriété)

• Ils ont une portée utilisateur et application, permettant de stocker des valeurs par défaut

• Ils sont pris en charge dans la section de configuration de Visual Studio

• Les chaînes longues et / ou les données avec des caractères spéciaux sont très bien prises en charge (par exemple, les chaînes JSON incorporées contenant des guillemets doubles)

Les inconvénients

• Les paramètres utilisateur sont stockés dans un endroit différent du profil utilisateur (avec un chemin cryptique), peuvent être difficiles à nettoyer

• Les paramètres de l'étendue de l'application sont en lecture seule pendant l'exécution de l'application (seuls les paramètres de l'étendue de l'utilisateur peuvent être modifiés pendant l'exécution)

• Code de méthodes de lecture / écriture construit par le concepteur de paramètres de Visual Studio, non directement fourni par des outils tiers (voir le lien ci-dessus pour une solution de contournement)

AppSettings dans .NET
Update: AppSettings dans .NET Core
(cliquez ci-dessus pour afficher le code source et les détails techniques)

Avantages

• Sont "légers", c'est-à-dire faciles à manipuler

• Accès en lecture et en écriture pendant l'exécution de l'application

• Ils peuvent être modifiés facilement par les administrateurs dans le
  Gestionnaire des services Internet (IIS)
  ^{(Affichage des fonctionnalités -> Paramètres de l'application, notez que le nom de l'icône est trompeur car il ne peut gérer que AppSettings et non ApplicationSettings)}

Les inconvénients

• Prend en charge uniquement les données de chaîne; la longueur de la chaîne et les caractères spéciaux sont limités

• Ils n'ont pas de portée utilisateur

• Ils ne prennent pas en charge les valeurs par défaut

• Ne sont pas directement pris en charge dans la section de configuration de Visual Studio

J'aime travailler avec la version plus simple pour stocker et accéder à des valeurs uniques.

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

J'ai écrit une classe utilitaire pour accéder aux valeurs d'une manière sécurisée qui permet les valeurs par défaut. Si les valeurs par défaut ne sont pas fournies, des messages d'exception utiles sont fournis.

Vous pouvez voir / télécharger la classe ici:

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