Pourquoi utiliser app.config pour stocker des données de configuration ?

Question

Je suis actuellement en train de compléter une application qui a été commencée par quelqu'un d'autre. Il utilise le fichier app.config pour certains paramètres, et un fichier xml personnalisé pour d'autres parties. Cela me rend fou, et je veux consolider la configuration dans un seul fichier.

Mais je ne suis pas certain de déplacer tout dans le app.config et jeter le fichier xml personnalisé, ou déplacer tout dans l'autre fichier et oublier le app.config.

Je vois deux arguments, un pour chaque option :

1. Utiliser la manière standard fournie par Visual Studio est plus facile à maintenir pour quelqu'un d'autre que moi.
2. Je peux valider le fichier personnalisé contre mon propre schéma xml, externalisant ainsi de nombreux tests si le fichier de configuration contient toutes les données requises, etc.

Mais je suis certain qu'il y a beaucoup plus de choses que je ne peux pas imaginer pour le moment. C'est pourquoi je demande :

Quels sont les avantages ou les inconvénients d'utiliser app.config pour stocker votre configuration par rapport au fichier de configuration 'traditionnel' ?

Answer 1

Le principal avantage d'utiliser le fichier app.config est que c'est le moyen par défaut et pris en charge pour une application .NET de stocker sa configuration. Toute personne utilisant cette application ou l'héritant de votre part vous remerciera d'utiliser des normes établies au lieu de "réinventer la roue".

De plus, le framework .NET prend en charge l'utilisation, l'écriture, la création, la modification du fichier app.config - si vous allez avec votre propre schéma, vous devrez réinventer la roue de nombreuses fois.

Je recommanderais donc certainement d'utiliser app.config - c'est LA manière de faire la configuration en .NET et une norme largement acceptée et bien supportée.

Marc

Answer 2

Diviser la configuration en différents fichiers est très utile si le cycle de vie de votre projet l'amène à passer d'un environnement à un autre.

Par exemple, lorsque les développeurs travaillent sur le code, vous pouvez vouloir que l'application pointe vers la boîte 'devsql'. Lorsqu'il est temps d'effectuer des tests de validation, le code est déployé sur un serveur de staging, et vous voulez que l'application pointe vers 'stagingsql'.

Si vous gardez toutes les configurations dans app.config, et qu'un changement de paramètres a été apporté à la version dev de app.config, il sera copié et écrasera la version de staging - maintenant vos validateurs pointent vers la base de données dev.

En gardant 'database.xml' séparé de 'app.config', vous pouvez permettre des différences entre les différents environnements, tout en permettant toujours aux changements des fichiers de configuration de passer de chaque environnement au suivant sans craindre d'écraser une personnalisation.

Answer 3

IMHO app.config n'est pas un moyen très pratique de stocker des données de configuration, principalement pour ces deux raisons :

• Vous n'avez aucun contrôle sur l'emplacement du fichier
• Vous ne pouvez pas définir votre propre structure pour organiser les paramètres de configuration

Je préfère utiliser ma propre classe de configuration, que je charge et enregistre en utilisant la sérialisation XML. Vous obtenez toujours les avantages des paramètres fortement typés, et c'est beaucoup plus flexible car vous pouvez définir n'importe quelle structure que vous voulez

Answer 4

App.config a un bon support pour les configurations de connexion et de journalisation, que vous utiliserez dans presque toutes les applications. Les réécrire peut vous apporter beaucoup de travail. De plus, vous pouvez avoir une certaine flexibilité de structure si vous utilisez "sectionGroup" dans votre app.config.

Mais avant de faire quelque chose, je demanderais à la personne qui a créé le fichier de configuration personnalisé pourquoi il l'a fait. Il y a des situations inhabituelles dans lesquelles app.config peut vous poser problème, comme si vous voulez charger une autre DLL (avec sa propre app.config) par Assembly.Load. Dans ce cas, vous devrez consolider les deux configurations dans un seul app.config, et prier pour qu'ils n'aient pas de configuration avec la même clé.

Dans les webtests, vous ne pouvez pas remplacer les configurations de web.config, ce qui peut aussi poser problème, selon ce que vous voulez faire.

Mais à mon avis, ce n'est que dans des situations inhabituelles que app.config ne fera pas bien son travail. Dans la plupart des cas courants, je pense que cela ne vaut pas la peine de créer votre propre cadre de configuration.

Answer 5

Simplicité et lisibilité du programme.

App.config est une méthode normale dans .NET pour stocker des configurations, donc il est probable que d'autres programmeurs l'aient déjà vue. Il est stocké en XML, donc il n'y aura pas de différence de performance par rapport à un fichier de configuration XML.

Il gère également l'emplacement où enregistrer l'app.config (Documents and Settings/nom d'utilisateur/Local Settings/Application Data/votre application/) et enregistre automatiquement les configurations en fonction de l'emplacement et de la version de votre application, permettant à plusieurs versions de la même application de coexister.

Je dirais qu'il n'est pas nécessaire d'avoir à la fois app.config et un fichier XML personnalisé, donc combiner les deux pourrait être une bonne idée.