Недавно я использовал JPOS для имитации финансовых транзакций на основе ISO 8583. Я заметил, что в JPOS любят использовать множество XML-файлов в качестве параметров конфигурации. У меня возникает вопрос, почему они выбирают этот подход? Я хочу разработать более крупное приложение, которое может работать с большим количеством серверов/терминалов/транзакций/баз данных/внешних одноранговых узлов (на основе TCP/IP через ISO-8583)/много параметров в БД, когда я пытался представить себе такое программное обеспечение с JPOS я пришел к большой папке развертывания с множеством важных файлов, которые сложно настроить и которые требуют миграции из записей в таблицах в теги XML. Мой вопрос: почему они используют файловую систему для хранения конфигураций, и стоит ли использовать такое количество XML-файлов, или мне следует внести изменения в свое программное обеспечение и позволить ему считывать конфигурации из БД? (поскольку проще управлять резервным копированием/изменением/ Архивировать/управлять авторизациями и прочим в БД)
Оптимизировано ли иметь все параметры в файле XML?
Ответы (1)
Если вы посмотрите на историю jpos, конфигурация xml была доступна с самого начала, и проект довольно старый, но все еще очень активный. Существуют аргументы за и против конфигурации DB и XML.
Да, файлы конфигурации могут выйти из-под контроля для более крупных проектов. Сказав это, некоторыми настройками можно управлять с помощью шаблонов freemarker или подстановки параметров ant во время сборки или использовать такой компонент, как sysconfigconfigurationfactory, который может дать вам пример извлечения конфигурации из таблицы. Миграция существующих систем не всегда проста, вы можете запускать сценарии для создания файлов xml из вашей существующей конфигурации и сохранять их, ничто вас не остановит. Изменение файлов конфигурации и их сохранение приводит к горячей замене конфигурации и ее немедленному использованию. Нумерация файлов обеспечивает порядок загрузки компонентов и обработки зависимостей (тоже может быть проблемой). Другие конфигурации среды выполнения могут быть выполнены с использованием обычного доступа к БД через режим гибернации.
