Понимание параметров конфигурации .Net

Question

Меня действительно смущают различные параметры конфигурации для .Net конфигурации dll, веб-сайтов ASP.net и т. Д. В .Net v2 - особенно если учесть влияние файла конфигурации на пользовательский интерфейс / конечный пользователь цепочки .

Так, например, некоторые приложения, с которыми я работаю, используют настройки, к которым мы обращаемся:

string blah = AppLib.Properties.Settings.Default.TemplatePath;

Теперь эта опция кажется классной, потому что члены строго набраны, и я не смогу ввести имя свойства, которого нет в Visual Studio 2005 IDE. В итоге мы получаем строки вроде этого в App.Config исполняемого проекта командной строки:

<connectionStrings>
    <add name="AppConnectionString" connectionString="XXXX" />
    <add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>

(Если у нас нет второго параметра, кто-то, выпускающий отладочную dll для live box, мог бы создать встроенную строку отладочного соединения - eek)

У нас также есть настройки, доступные следующим образом:

string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];

Теперь они кажутся крутыми, потому что мы можем получить доступ к настройке из кода dll или кода exe / aspx, и все, что нам нужно в Web или App.config, это:

<appSettings>
   <add key="TemplatePath_PDF" value="xxx"/>
</appSettings>

Однако значение курса может быть не задано в файлах конфигурации, или имя строки может быть напечатано с ошибкой, поэтому у нас другой набор проблем.

Итак ... если я правильно понимаю, прежние методы дают строгую типизацию, но плохое распределение значений между dll и другими проектами. Последний обеспечивает лучший обмен, но более слабый набор текста.

Мне кажется, что я что-то упускаю. На данный момент я даже не обеспокоен тем, что приложение может записывать значения в файлы конфигурации, шифровать или что-то в этом роде. Кроме того, я решил, что лучший способ хранить любые строки, не связанные с подключением, - это использовать в БД ... и затем следующее, что я должен сделать, это сохранить телефонные номера для текстовых сообщений в случае проблем с подключением к БД, чтобы они должны храниться вне БД!

Answer 1

Если вы используете вкладку настроек в VS 2005+, вы можете добавить строго типизированные настройки и получить intellisense, как в первом примере.

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

Это физически хранится в App.Config.

Вы все еще можете использовать элемент appSettings файла конфигурации или даже свернуть свои собственные подклассы ConfigurationElementCollection, ConfigurationElement и ConfigurationSection.

Относительно того, где хранить настройки, базу данных или файл конфигурации, в случае строк без подключения: это зависит от архитектуры вашего приложения. Если у вас есть сервер приложений, который используется всеми клиентами, используйте вышеупомянутый метод в App.Config на сервере приложений. В противном случае вам, возможно, придется использовать базу данных. Размещение его в App.Config на каждом клиенте вызовет проблемы с версиями / развертыванием.

Answer 2

Нидж, наше различие в мышлении происходит с разных точек зрения. Я думаю о разработке корпоративных приложений, которые преимущественно используют клиенты WinForms. В этом случае бизнес-логика содержится на сервере приложений. Каждый клиент должен знать номер телефона для набора, но размещение его в файле App.config каждого клиента создает проблему, если этот номер телефона изменяется. В этом случае кажется очевидным хранить информацию о конфигурации приложения (или настройки всего приложения) в базе данных, и каждый клиент должен прочитать настройки оттуда.

Другой способ .NET (я делаю различие, потому что в прежние дни .NET мы сохраняли настройки приложения в таблицах БД) - это сохранение настроек приложения в файле app.config и доступ через сгенерированный класс настроек.

Я отвлекся. Ваша ситуация звучит иначе. Если все разные приложения находятся на одном сервере, вы можете разместить настройки в файле web.config на более высоком уровне. Однако, если это не так, у вас также может быть отдельная «служба конфигурации», с которой все три приложения общаются, чтобы получить свои общие настройки. По крайней мере, в этом решении вы не копируете код в трех местах, что повышает вероятность проблем с обслуживанием при добавлении настроек. Звучит немного по-инженерному, хотя.

Мое личное предпочтение - использовать строго типизированные настройки. Я на самом деле создаю свой собственный строго типизированный класс настроек на основе того, что это моя таблица настроек в базе данных. Таким образом, я могу получить лучшее из обоих миров. Intellisense для моих настроек и настроек, хранящихся в БД (примечание: это в случае, когда нет сервера приложений).

Я тоже заинтересован в изучении стратегий других людей:)

Answer 3

Да - я думаю, что я / мы находимся в ситуации головной боли, которую Роб снимает - у нас есть что-то вроде 5 или 6 разных веб-сайтов и приложений на трех независимых серверах, которым необходим доступ к одной и той же БД. В настоящее время каждый из них имеет свой собственный Web или App.config с описанными настройками и / или переопределением настроек в нашей основной библиотеке dll DB-access.

Роб - когда вы говорите сервер приложений, я не уверен, что вы имеете в виду? Самое близкое, что я могу подумать, это то, что мы могли бы по крайней мере поделиться некоторыми настройками между сайтами на одном компьютере, поместив их в файл web.config выше в иерархии каталогов ... но я тоже не смог исследовать это ... подумав, что важнее понять, какой из маршрутов с сильным или слабым типом «лучше».

Answer 4

Я поддерживаю ответ Роба Грейса, но хотел немного добавить к нему. Это может быть слишком очевидно, но если вы используете несколько клиентов, app.config должен хранить все параметры, относящиеся к установке, а база данных должна хранить почти все остальное.

Приложения для одного клиента (или сервера) несколько отличаются. Здесь это на самом деле более личный выбор. Заметное исключение может произойти, если параметр является идентификатором записи в базе данных, и в этом случае я всегда буду сохранять параметр в базе данных с внешним ключом, чтобы ссылка не удалялась.

Answer 5

Я думаю, что ваше замешательство связано с тем, что ваш первый пример - домашняя библиотека, а не часть .NET. Пример менеджера конфигурации является примером встроенной функциональности.