Руководство по проектированию конфигурации системы?

Question

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

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

Что-то в глубине моего сознания постоянно говорит мне, что это не лучший способ сделать это. Итак, мой вопрос: есть ли шаблоны проектирования или рекомендации для проектирования системы конфигурации? Когда и как система конфигурации должна считывать конфигурацию и как она должна предоставлять эту информацию остальной части приложения? Это должен быть синглтон? Я не спрашиваю о рекомендуемых механизмах хранения (XML против базы данных против текстового файла ...), хотя мне также интересен ответ на этот вопрос.

Answer 1

Guidlines:

Рассмотрим управление настройками

• Как часто они могут быть изменены?
• Как их можно изменить и как они это делают?

E, G Для изменений в web.config требуется специалист, обладающий техническими навыками, и в результате ваше приложение будет перезагружено при его изменении; настройки where-as, к которым обращается пользовательский интерфейс, предоставленный системой, не будут иметь таких проблем.

Безопасность

• Вам нужно зашифровать какие-либо настройки?
• Вам нужно разделить настройки, чтобы только определенные люди могли получить к ним доступ?
• Нужно ли проводить какой-либо аудит изменений?

Соглашения об именах

• Есть немного.
• Я настоятельно рекомендую использовать подход на основе URI для установки ключей - это помогает избежать коллизии между различными настройками между различными компонентами (вероятно, когда вы начинаете добавлять сторонние компоненты в вашу систему - или когда ваши добавляются к чужим.
• Ключи, основанные на URI, также упрощают обслуживание, так как легче увидеть, к чему применяется настройка.
• Существуют разные именования "схем", которые вы можете использовать, мне нравится отражать структуру кода, если я могу, но иногда вы можете захотеть следовать чему-то другому, например, бизнес-процессу.
• Не используйте неоднозначные имена, такие как «DatabaseConnection».

Пример ключа на основе URI:

   <appSettings>
        <add key="Morphological.RoboMojo.BusinessLogic.IJobDataProvider" value="Morphological.RoboMojo.XmlDataProvider.JobDataProvider, Morphological.RoboMojo.XmlDataProvider"/>
        <add key="Morphological.RoboMojo.BusinessLogic.ITaskDataProvider" value="Morphological.RoboMojo.XmlDataProvider.TaskDataProvider, Morphological.RoboMojo.XmlDataProvider"/>
        <add key="Morphological.RoboMojo.XmlDataProvider.NameAndPathOfDataFile" value="C:\Program Files (x86)\Morphological Software Solutions\RoboMojo\RoboMojoState.txt"/>
        <add key="Morphological.RoboMojo.XmlDataProvider.PathOfDataFileBackups" value="C:\Program Files (x86)\Morphological Software Solutions\RoboMojo\RoboMojoState Backups"/>
        <add key="Morphological.RoboMojo.BusinessLogic.ITaskExecutorProvider" value="Morphological.RoboMojo.TaskExecutorMSRoboCopy.RoboMojo, Morphological.RoboMojo.TaskExecutorMSRoboCopy"/>
        <add key="Morphological.RoboMojo.TaskExecutorMSRoboCopy.LocationOfRoboCopyEXE" value="C:\Windows\System32\RoboCopy.EXE"/>
    </appSettings>

Answer 2

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

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

Для этого я обычно используюСинглтон-объект «root config», который имеет методы, которые предоставляют дополнительные уровни иерархии и свойства конфигурации на каждом уровне. Корень отвечает за разрешение иерархии, но при необходимости (например, для настройки config) вы можете самостоятельно пройти через иерархию для решенияс сеттинgs относится к одному уровню в иерархии.

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

Если нет, вы можете кэшировать настройки вместе с датой «последнего чтения» ипросто перечитайте значения настроек в кеш после истечения срока действия.