Как мне управлять конфигурацией приложения в ASP.NET? - PullRequest
Новая
       17

Как мне управлять конфигурацией приложения в ASP.NET?

5 голосов
/ 23 марта 2010

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

Какие-либо предложения по лучшим методам обработки этого или хорошим источникам информации для исследования?

Как мы делаем вещи в настоящее время:

  • Различные файлы конфигурации xml, на которые есть ссылки в Web.Config, например, AppSettings.xml.
  • Конфигурации для определенных сайтов хранятся в дубликатах конфигурационных файлов.
  • Текстовые файлы, содержащие списки данных, относящихся к сайту
  • В некоторых случаях ручные одноразовые изменения в базе данных
  • C # конфигурация для Виндзорского МОК.

Конкретные проблемы, с которыми мы сталкиваемся:

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

Наши нынешние мысли о том, как мы можем подойти к этому:

  • Переместить конфигурацию в динамически скомпилированный код (возможно, Boo, Binsor или JavaScript)
  • Имеют некоторую форму конфигурации сравнения / объединения: объедините конфигурацию по умолчанию с конфигурацией live / test / training и конфигурацией, специфичной для сайта

Ответы [ 3 ]

2 голосов
/ 03 апреля 2010

Какой бы путь вы ни выбрали, я думаю, что было бы полезно иметь понятие единого «источника правды» для вашей конфигурации.

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

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

В зависимости от уровня мастерства ваших партнеров по поддержке (независимо от того, будут ли они ломать XML), я думаю, вы также можете захотеть предоставить утилиту с графическим интерфейсом, которая позволит им вертеть все ручки в этом файле конфигурации «Истина правды» с "Apply" запускает и запускает код преобразования / обновления, чтобы внести необходимые изменения в Web.config & friends.

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

Примечание: В ASP.NET 4.0 будет доступен механизм преобразования конфигурации во время сборки (см. http://blog.hmobius.com/post/2010/02/17/ASPNET-40-Part-4-Config-Transformation-Files.aspx),, который может упростить эту задачу. Похоже, вы можете использовать это с некоторыми хаки для не веб-проектов (см. http://philbolduc.blogspot.com/2010/03/using-config-transforms-outside-web.html).

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

0 голосов
/ 24 марта 2010

Вы можете рассмотреть возможность просмотра сценариев NAnt для автоматизации в сочетании с некоторой пользовательской утилитой .net для управления ключами конфигурации.

0 голосов
/ 23 марта 2010

Если код, использующий указанные элементы конфигурации, является кодом, которым вы управляете / который можете изменить (и все это выполняется в пространстве управляемого кода / C #), я хотел бы перенести вызовы методов, которые получают настройки для вызова, в одноэлементный класс с at хотя бы метод GetString () для него.

GetObject () может быть очень полезным (ознакомьтесь с сериализацией XML .Net - американцы пишут это с помощью 'z': сериализация) ... полезно для многих вещей, но также потому, что это означает, что вы можете начинать упаковку, связанную с элементы конфигурации в отдельные записи в магазине.

Что касается использования одного хранилища (таблицы базы данных с кэшированным доступом) или использования вашего нового фасада конфигурации только для инкапсуляции, где хранятся элементы конфигурации - это ваше дело ... Я настоятельно предпочитаю один магазин на развертывание продукта для конфигурации, потому что тогда вы всегда точно знаете, где искать и где вносить изменения. Все ссылки на веб-сервисы (WCF или иные) могут быть созданы и вызваны с использованием предоставленных во время выполнения строк ...:)

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

EDIT Что-то вроде: 

public class ConfigurationStore
{
    private static ConfigurationStore _instance = null;

    public static ConfigurationStore Instance {
        get {
        if(_instance == null)
        {
            _instance = new ConfigurationStore();
        }

        return _instance;
        }
    }

    public string GetValue(string key)
    {
        ....
    }

    public Object GetObject(string key)
    {
        ...
    }
}
...