ConfigurationSettings vs Properties.Settings

Question

J'ai une application Winform qui a 16 connexions SQL actuellement stockées dans les projets DAL Settings.settings. J'essaie d'écrire une classe "Manager" pour simplifier cela (commehere). Cependant, la plupart des exemples que je trouve sur le web semblent utiliser ConfigurationSettings.AppSettings["something"]. Pendant que j'utilisais Properties.Settings.Default.something.

Quelqu'un peut, s'il vous plaît, expliquer ce qui est considéré comme CORRECT et pourquoi pour une application de bureau?

Answer 1

Je n'ai jamais été un grand fan de mettre des chaînes de connexion sql dans les fichiers de configuration pour le logiciel. Les utilisateurs ont l'habitude de les gâcher par curiosité ou stupidité (ou une combinaison des deux). J'aime mettre toutes mes chaînes de connexion (développement, modèle, production, peu importe) dans les propriétés de ma bibliothèque d'accès aux données, et y inclure une classe ConfigurationSettings que j'utilise pour y accéder en fonction d'une propriété définie par le consommateur Application:

public class ConfigurationSettings 
{ 

    public static string MyConnectionString 
    { 
    get 
      if(ConfigurationSettings.TestMode) 
       return Properties.Settings.Default.MyConnectionStringTest; 
      else 
       return Properties.Settings.Default.MyConnectionStringProd; 
    } 
    } 

    // I typically only have test and not-test. This could 
    // easily be some other combination of values to satisfy 
    // multiple environments. 
    public static bool TestMode { get; private set;} 
} 

cela me permet d'appeler les propriétés statiques de cette classe par un nom commun et ont toutes les chaînes de connexion disponibles en fonction de certains critères. Cela permet à vos ensembles de données spécifiques, entités, quel que soit le modèle de données que vous utilisez, de se préoccuper des chaînes de connexion et les paramètres peuvent être compilés dans le fichier .dll (et ne plus avoir à se soucier d'eux). Cette méthode peut également être modifiée pour tirer les paramètres d'un app.config (ce que je fais pour les sites ASP.Net) dans une méthode similaire. MISE À JOUR: Il n'y a vraiment pas de manière "correcte" comme vous le supposez. Le fichier app.config a été conçu pour contenir les paramètres de configuration modifiables sans avoir à reconstruire l'application. Les paramètres de propriété ont été conçus pour contenir des paramètres qui ne sont pas modifiables. Donc les deux sont parfaitement valables. Probablement le moyen le plus "correct" est un moyen qui a du sens à la fois pour votre application et pour votre équipe de développement.

Answer 2

Je pense que la bonne façon est d'utiliser le fichier app.config et de les stocker dans la section connectionStrings?

Ensuite, vous pouvez y accéder comme:

ConfigurationManager.ConnectionStrings["something"].ConnectionString 

Vous pouvez écrire un wrapper autour de cela facilement si cela est trop « laid ».

public class ConnectionManager 
{ 
    public string Something 
    { 
     get 
     { 
      // TODO: check to make sure the configuration exists and throw an exception perhaps 
      return ConfigurationManager.ConnectionStrings["something"].ConnectionString; 
     } 
    } 
} 

Oups ... comme indiqué que je voulais faire ConfigurationManager et non ConfigurationSettings.

Answer 3

Properties.Settings.Default sont généralement utilisés pour enregistrer l'état interne de l'application comme la couleur de l'arrière-plan, pour mémoriser les paramètres de l'utilisateur. ConfigurationSettings est en fait la classe "Manager" dont vous parliez et peut accéder à d'autres jeux de paramètres personnalisés à partir du fichier app.config, y compris les chaînes de connexion.

Answer 4

Nous préférons utiliser Properties.Settings (aka settings.settings) car il est fortement typé. N'essayez pas de faire des astuces qui ont des environnements différents (dev/prod) dans le même fichier de configuration. Il est beaucoup plus facile d'avoir un fichier de configuration séparé par environnement, et de renommer les configs lorsque vous les déployez. c'est à dire.

app.config 
app.stage.config 
app.test.config 
app.prod.config 

Nous utilisons PowerShell scripts (fichiers batch sur les stéroïdes) pour faire nos déploiements. Je vais simplifier ce que nous faisons en tant que fichier batch traditionnel - (pseudo code/échantillon non testé):

@echo off 
:: %1 is the environment name (first parameter) 
setlocal 
set source=c:\tfs\project\bin\release\ 
set target=\\server\share\path\ 

xcopy /s/e %source% %target% 

:: Using a copy command to rename/overwrite the env specific version 
if exists %target%\app.%1.config copy /y %target%\app.%1.config %target%\app.config