Рекомендации по настройке конфигурации - PullRequest
5 голосов
/ 29 декабря 2008

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

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

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

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

Добавлен-1

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

Добавлен-2

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

Ответы [ 3 ]

1 голос
/ 30 декабря 2008

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

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

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

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

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

1 голос
/ 29 декабря 2008

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

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

0 голосов
/ 29 декабря 2008

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

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

...