Где хранить файлы конфигурации

Question

Я создал новый проект C # (не веб) для нашей реализации PayPal. У меня есть куча строк конфигурации, таких как следующие, которые мне нужно выяснить, лучший способ хранения. Различные классы-оболочки, которые я создал, используют эти строки. Кроме того, это проект, который можно использовать в любом веб-проекте или даже в бэк-энде. Поэтому мне нужен хороший способ избавиться от них, чтобы другие приложения не понадобились, и централизовать все эти строковые ключи в моем проекте PayPal C # для их поддержки. Другие приложения, использующие мой проект-обертку, не должны ничего знать об этих строках или должны ... мой проект заботится о их хранении.

С этим, где? Использую ли я Web.Config в моем не # веб-проекте на C #? Я использую конфигурацию приложения? Я храню их в БД (нет, плохая идея). ИЛИ я могу хранить их как константы, например, в классе Constants.cs?

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

Answer 1

Если строки определены во время компиляции и никогда не меняются, используйте файл ресурсов.

Если им требуется постоянное хранилище, вы также можете использовать системный реестр - я сам балуюсь этим, также использую файлы ресурсов для уменьшения критических опечаток:

// Get key
RegistryKey appKey = Registry.CurrentUser.CreateSubKey(Resources.keyAppPath);

// Read from key
string _configStr = (string)appKey.GetValue(Resources.keyConfigStr, string.Empty);

// Write to key
appKey.SetValue(Resources.keyConfigStr, _configStr);

Resources.keyAppPath похоже на "Software\[Company]\[App]"

Resources.keyConfigStr - это имя ключа.

Как уже упоминалось, добавьте слой шифрования, если безопасность связана с конкретными данными!

Answer 2

Мы сделали реализацию PayPal некоторое время назад. В итоге мы сохранили эти чувствительные строки в виде зашифрованных строк в web.config. Я думаю, что для вашего сценария вы могли бы подумать о том, чтобы сделать что-то подобное (хранить как зашифрованные строки в web.config), но централизовать его, обернув его только веб-службой intranet и предоставляя доступ только к одной учетной записи домена. Это гарантирует, что никто, кроме одной учетной записи домена, не сможет вызвать веб-службу для получения учетных данных или других конкретных объектов PayPal.

Answer 3

Просто используйте систему конфигурации .NET (System.Configuration) и не беспокойтесь о том, где хранятся параметры конфигурации.

Если ваш код используется не из веб-приложения, эти настройки можно настроить в файле .config приложения. Веб-приложение будет использовать web.config.

Несмотря на разные имена, app.config и web.config используют один и тот же API.

Answer 4

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

Answer 5

Вы могли бы просто создать простой класс, содержащий их, xmlSerialize класс туда, куда вы хотите, чтобы его читали обратно в тот же класс другие приложения.

Answer 6

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

Я использовал метод web.config, который создает мои собственные разделы конфигурации и разделы строки подключения в зависимости от уровня или типа сервера, который обращается к нему. Затем я создал свой собственный класс «ConfigurationManager», который обращается к ним способом, почти идентичным встроенному в ConfigurationManager (поэтому его использование будет прозрачным для других разработчиков). Тогда в моем файле web.config могут быть любые настройки, и сам класс можно использовать одинаково для всего предприятия в соответствии со стандартами конфигурации ASP.Net. Любой, кто нуждается в настройке, вызовет myConfigurationManager.AppSettings (key) и получит соответствующую настройку в зависимости от уровня рассматриваемого сервера, и исходный элемент управления для файла конфигурации не должен будет отличаться для разных серверов.

Аналогичным образом можно настроить app.config для обеспечения расширенной поддержки конфигурации.