ConfigurationSettings vs Properties.Settings

Ich habe eine Winform-App, die derzeit 16 SQL Connections in den DAL Projects Settings.settings gespeichert hat.

Ich versuche eine "Manager" -class zu schreiben, um dies zu vereinfachen ( wie hier ). Die meisten Beispiele, die ich im Internet finde, scheinen jedoch ConfigurationSettings.AppSettings["something"] . Während, ich benutzte Properties.Settings.Default.something . Properties.Settings.Default.something . Properties.Settings.Default.something . Properties.Settings.Default.something .

Kann jemand bitte erklären, was als RICHTIG angesehen wird und warum für eine Desktop-Anwendung?

Solutions Collecting From Web of "ConfigurationSettings vs Properties.Settings"

Ich war nie ein großer Fan von SQL-Verbindungszeichenfolgen in configurationsdateien für Software. Die Benutzer haben die Angewohnheit, sie aus Neugier oder Dummheit (oder einer Kombination der beiden) zu vermasseln. Ich möchte alle meine Verbindungszeichenfolgen (Entwicklung, model, Produktion, was auch immer) in die properties meiner datazugriffsbibliothek insert und darin eine ConfigurationSettings-class einschließen, die ich für den Zugriff auf sie basierend auf einer Eigenschaft verwende, die von dem Benutzer festgelegt wird Anwendung:

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

Dadurch kann ich die staticen properties dieser class über einen allgemeinen Namen aufrufen und alle Verbindungszeichenfolgen abhängig von einigen Kriterien verfügbar haben. Dadurch werden Ihre spezifischen datamengen, Entitäten und datamodelle, die Sie verwenden, daran gehindert, sich Gedanken über Verbindungszeichenfolgen zu machen, und die Einstellungen können in die DLL kompiliert werden (und müssen sich nicht mehr um sie kümmern). Diese Methode kann auch geändert werden, um Einstellungen aus einer app.config (die ich für ASP.Net-Sites mache) in einer ähnlichen Methode zu ziehen.

UPDATE: Es gibt wirklich keinen "richtigen" path, wie du andeutest. Die app.config wurde entworfen, um configurationseinstellungen zu speichern, die geändert werden können, ohne die Anwendung neu zu erstellen. Die propertieseinstellungen enthielten Einstellungen, die nicht geändert werden können. Also beide sind absolut gültig. Wahrscheinlich ist der "richtige" path ein path, der sowohl für Ihre Anwendung als auch für Ihr Entwicklungsteam sinnvoll ist.

Ich denke, der richtige path ist, die file app.config zu verwenden und sie im Abschnitt connectionStrings zu speichern?

Dann können Sie wie folgt auf sie zugreifen:

  ConfigurationManager.ConnectionStrings["something"].ConnectionString 

Du könntest leicht einen Wrapper schreiben, wenn das zu "hässlich" ist.

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

Hoppla … wie gesagt, ich wollte ConfigurationManager und nicht ConfigurationSettings machen.

Wir bevorzugen es, Properties.Settings (alias settings.settings) zu verwenden, da es stark typisiert ist. Versuche nicht, ausgefallene Tricks mit unterschiedlichen Umgebungen (dev / prod) in derselben configurationsdatei auszuführen. Es ist viel einfacher, eine separate configurationsdatei pro Umgebung zu haben und die configurationen beim Deployment umzubenennen. dh

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

Wir verwenden PowerShell- Skripte (Batch-fileen auf Steroiden), um unsere Bereitstellungen durchzuführen. Ich werde vereinfachen, was wir als traditionelle Batch-file tun – (Pseudocode / ungetesteten Probe):

 @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 

Im Allgemeinen werden Properties.Settings.Default verwendet, um den internen Status der Anwendung wie die Farbe des backgrounds zu speichern und Benutzereinstellungen zu speichern.

ConfigurationSettings ist eigentlich die class "Manager", über die Sie gesprochen haben, und kann über die file app.config auf andere benutzerdefinierte Einstellungen zugreifen, einschließlich Verbindungszeichenfolgen.