Лучшие практики по параметрам конфигурации

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

Просто интересно, что является хорошим стандартом с точки зрения сохранения настроек приложения в сборках для упрощения развертывания.

Я думаю, я смотрю на это из двух сценариев:

  1. Внутреннее приложение (будь то большое .com или небольшое приложение для администратора).
  2. При создании API для использования другими, как ссылаться на параметры конфигурации, когда вы не знаете, какие конечные значения будут у потребителя, который будет использовать ваш API в своем приложении.

Добавлено-1:

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

Добавлено-2:

А как насчет того, когда вы создаете API для использования. Допустим, у вас есть класс, который будет извлекать определенную информацию о конфигурации, но эти конечные точки (свойства) не определены до тех пор, пока клиент не использует ваш API (в частности, C#/.NET)? Где и как бы вы установили эти свойства, скажем, в классе конфигурации, который вы создаете, например «ApplicationDefinitions»?


person Community    schedule 29.12.2008    source источник
comment
Вам действительно нужно предоставить некоторую информацию о том, для какой среды это нужно. Иначе этот вопрос просто разлетится по 1000 направлениям.   -  person krosenvold    schedule 29.12.2008


Ответы (3)


Если это касается нескольких приложений, вы можете (очень осторожно) поместить настройки в machine.config.

Или у вас может быть отдельный общий файл репозитория настроек конфигурации, который считывается и используется для создания нового web.config каждый раз, когда вы создаете свое веб-приложение/решение.

person Kon    schedule 29.12.2008
comment
Какую платформу вы предполагаете? Где хранится файл machine.config или файл web.config? - person Jonathan Leffler; 29.12.2008
comment
Простите... это специфично для .NET - person Kon; 30.12.2008

Мы должны поддерживать несколько UAT (пользовательских приемочных тестов), производственных сред, сред разработки и аварийного восстановления.

В идеале вся эта информация должна храниться на одном гигантском сервере LDAP.

В реальном мире мы написали задачу ANT, которая использует Jakarta-Velocity в качестве механизма шаблонов. Это создает несколько файлов (UAT, DEV, PROD, DR) из одного файла шаблона.

У нас есть центральный файл, который используется для всех обычных вещей, и файлы меньшего размера для отдельных приложений. Командная строка для любого приложения должна знать, выполняется ли это система UAT/DEV.. и т. д., затем она загружается в общий файл и файл, специфичный для приложения.

Это очень хорошо работает на практике, и мы используем его уже около 8 лет. Я видел много других людей, пытающихся манипулировать несколькими файлами приложений для всех своих сред, и это НЕ красиво. Ошибки делаются часто.

person Fortyrunner    schedule 29.12.2008

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

Если вы программируете в .Net, то настройки, которые являются общими для нескольких приложений, могут быть сохранены в machine.config... опять же, не помещайте их непосредственно в machine.config, а создайте ссылку на отдельный файл ( используя настраиваемый атрибут configSection и configSource="" для создания косвенной ссылки на этот отдельный файл...

person Charles Bretana    schedule 29.12.2008