Моя конфигурация приложения очень иерархична и прекрасно вписывается в один XML. Вскоре (YAGNI, Yeh) части этой информации будут удалены другими приложениями удаленно, что потребует базы данных.
Итак, я вошел в разработку таблиц БД и вернул их обратно в иерархию классов приложений (используя EF). однако это стало кошмаром для обслуживания.
Мне бы хотелось услышать от других опыт рассмотрения этой проблемы, спасибо.
У нас был очень хороший опыт хранения конфигурации в базе данных для долгосрочных приложений (например, веб-сайтов и служб). Преимущества:
select max(lmod) from config) или по сигналу (пинг веб-страницы или где-то создать пустой файл)Основная проблема заключается в редактировании, если у вас сложная иерархическая структура конфигурации со значениями по умолчанию, списками и наследованием. Наши решения:
Конфигурационные объекты скрывают эти детали, поэтому приложение просто работает с объектами.
Специальный класс отвечает за повторное чтение конфигурации в случае изменения. Обычно мы обновляем конфигурацию некоторое время в течение дня, и задание по времени перезагружает его через часы. Таким образом, нам не нужно синхронизировать методы конфигурации.
Резервирование и история изменений были проблемой. Мы исправили это, используя XML файлы в VCS, которые затем "загружены" в БД. Таким образом, мы можем проверить конфигурацию производства перед ее загрузкой (используя его с помощью специального набора модульных тестов на машине разработчика). Когда он активировался ночью, он обычно работал сразу, а оператор, ответственный за приложение, просто должен был немного поработать над тестированием.
Конфигурация IMHO должна жить в файлах, файлы хорошо работают для людей, и они подходят для компьютеров. БД хорошо работают для больших данных, но они слишком много для людей. Эти два, как правило, взаимоисключающие, и когда вы пытаетесь их объединить, вы получаете что-то вроде реестра - uggh.
Почему бы не оставить конфигурацию в файле и создать вокруг нее DAL и сервисный уровень, чтобы ваши приложения могли его использовать. Предполагается, что вы можете размещать на центральном сервере, если не иметь несколько копий файла в дикой природе.
Использование базы данных (возможно, для хранения этого файла конфигурации xml, если вы хотите сохранить формат) имеет свои преимущества: вы можете регистрировать/выполнять аудит изменений в конфигурации, а также делать резервное копирование и восстановление.
В основном ваш вопрос (то, как я его вижу) смешивает две вещи,
Вы можете легко сохранить файл конфигурации xml в базе данных и предоставить интерфейс для редактирования/отображения информации.
Конфигурационные файлы должны быть самыми легкими для обработки - поэтому помещайте их в файлы. Таким образом, кто-то может внести изменения там даже с помощью блокнота (при необходимости). База данных действительно переполнена, если вы не хотите, чтобы ваша конфигурация находилась на каком-то глобальном сервере и всех экземплярах, чтобы поделиться им.