ConfigurationSettings vs Properties.Settings

Question

У меня есть приложение Winform, в котором в настоящее время хранится 16 подключений SQL в проектах DAL Settings.settings.

Я пытаюсь написать класс "Manager", чтобы упростить это ( вроде здесь ). Тем не менее, большинство примеров, которые я нахожу в Интернете, похоже, используют ConfigurationSettings.AppSettings["something"]. Хотя я использовал Properties.Settings.Default.something.

Может кто-нибудь объяснить, пожалуйста, что считается ПРАВИЛЬНЫМ и почему для настольных приложений?

Answer 1

Я думаю, что правильным способом является использование файла app.config и его сохранение в разделе connectionStrings?

Тогда вы можете получить к ним доступ, например:

 ConfigurationManager.ConnectionStrings["something"].ConnectionString

Вы можете написатьОберните это легко, если это слишком "некрасиво".

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

Упс ... как уже указывалось, я хотел сделать ConfigurationManager, а не ConfigurationSettings.

Answer 2

Мы предпочитаем использовать Properties.Settings (aka. Settings.settings), потому что он строго типизирован. Не пытайтесь делать причудливые трюки с разными средами (dev / prod) в одном и том же файле конфигурации. Гораздо проще иметь отдельный файл конфигурации для каждой среды и переименовывать конфигурации при их развертывании. т.е.

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

Мы используем PowerShell сценарии (пакетные файлы на стероидах) для наших развертываний. Я упросту то, что мы делаем, как традиционный пакетный файл - (псевдокод / ​​непроверенный пример):

@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

Answer 3

Я никогда не был большим поклонником помещения строк подключения sql в файлы конфигурации для программного обеспечения.Пользователи имеют привычку обманывать их из любопытства или глупости (или какой-то их комбинации).Мне нравится помещать все свои строки подключения (разработка, модель, производство и т. Д.) В свойства моей библиотеки доступа к данным и включать в нее класс ConfigurationSettings, который я использую для доступа к ним на основе некоторого свойства, которое устанавливается потребляющим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;}
}

Это позволяет мне вызывать статические свойства этого класса через общее имя и получать все строки подключения в зависимости от некоторых критериев.Это позволяет получить ваши конкретные наборы данных, сущности, любую модель данных, которую вы используете, из-за беспокойства о строках соединения и настройках, которые можно скомпилировать в .dll (и больше не нужно беспокоиться о них).Этот метод также можно изменить, чтобы получить настройки из файла app.config (который я делаю для сайтов ASP.Net) аналогичным способом.

ОБНОВЛЕНИЕ: действительно, как вы подразумеваете, «правильного» способа не существует.App.config был разработан для хранения параметров конфигурации, которые можно изменять без перестройки приложения.Настройки свойств были разработаны для хранения настроек, которые нельзя изменить.Таким образом, оба совершенно действительны.Вероятно, самый «правильный» путь - это способ, который имеет смысл как для вашего приложения, так и для вашей команды разработчиков.

Answer 4

Properties.Settings.Default обычно используются для сохранения внутреннего состояния приложения, такого как цвет фона, для запоминания пользовательских настроек.

ConfigurationSettings фактически является классом «Manager», о котором вы говорили, и может получить доступ к другим настраиваемым наборам настроек из файла app.config, включая строки подключения.