Лучшая схема ASP.NET ConfigSection для DB

Question

Ранее настройки развертывания приложения ASP.NET хранились в нескольких файлах конфигурации в разделах конфигурации Web.config с использованием формата KEY/VALUE. Мы перемещаем эти «параметры модуля сайта» в базу данных по разным причинам.

Ниже перечислены обе опции, которые мы сейчас обдумываем:
1. Одна таблица с ключом applicationId, moduleId и ключом как основной ключ с полем Значение.
Плюсы:
- Это код воспроизводимого файла.
- Легко выбрать целые разделы для кэширования в объектах hashtables/value.
Против:
- Сложнее обновлять, так как каждый ключ необходимо обновлять индивидуально.
- Должен выдавать каждое значение, если оно не является строкой.

2. Отдельные столы для каждого раздела, которые отделяют хранимые процедуры, классы и т.д.
Плюсы:
- Данные гарантированно соответствовать, так как столбец и типы объектов набираются.
- Обновление выполняется за одну поездку к базе данных через явный интерфейс.
Минусы:
- Должны изменить интерфейс приложения для доступа к
- Необходимо обновить объекты, таблицу базы данных и хранимые процедуры каждый раз, когда что-то меняется.

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

Answer 1

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

Например:

/// <summary> 
/// The time passwords expire, in days, if ExpirePasswords is on 
/// </summary> 
public int PasswordExpirationDays { 
    get { return ParseUtils.ParseInt(this["PasswordExpirationDays"], PW_MAX_AGE);} 
    set { this["PasswordExpirationDays"] = value.ToString(); } 
} 

Answer 2

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

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

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

Наконец, если вы используете SQL Server (и, скорее всего, Oracle, хотя у меня нет опыта работы с Oracle и XML), и вы думаете о дизайне вашего класса настроек спереди, вы можете определить схему XML для вашего сериализованного объекта конфигурации поэтому вы можете использовать XQuery для быстрого получения значения параметра конфигурации без полного десериализации.

Answer 3

Это, как мы сделали это - Click Here

Мы были больше озабочены тем, что различные среды (Dev, Test, QA и Prod), имели различные значения для того же ключа. Теперь у нас есть только 2 ключа в файле WebEnvironment.Config, который никогда не продвигается. Первый ключ - это среда, в которой вы находитесь, а вторая - строка соединения.

таблица загружается один раз в словарь, а затем мы можем использовать его в коде, как это:

cApp.AppSettings["MySetting"];