Лучший ASP.NET ConfigSection для схемы БД

Question

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

Вот два варианта, над которыми мы сейчас обдумываем:
1. Одна таблица с applicationId, moduleId и ключом в качестве первичного ключа с полем Value.
Плюсы:
- Это имитирует доступ к файлу.
- Легко выбрать целые разделы для кэширования в объектах 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

Вот как мы это сделали - Нажмите здесь

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

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

  cApp.AppSettings["MySetting"];

Answer 3

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

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

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

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