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

Question

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

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

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

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

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

(Если мы не имеем вторую установку, кто-то выпускает отладки DLL в живом окне может быть построен со строкой отладки соединения встроенной в него - Ик)

у нас также есть настройки, доступ, как это:

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber; 

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

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

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

Answer 4

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

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

Answer 5

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

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