Каковы преимущества и недостатки использования XML для передачи данных в этой программе Java?
Мне было предложено написать графический интерфейс для существующей программы оболочки /cmdline, написанной на Java, и я хочу создать слой абстракции между графическим интерфейсом и исходной программой, что упростит добавление другого графического интерфейса ( например, веб-интерфейс, а не настольное приложение). На данный момент структура программы выглядит следующим образом:
![tU3Bh.png]()
Параметры командной строки немедленно переводятся в хэш-таблицу Java (с помощью опции -f opt
в хэш "-f=>opt"
). Эти параметры затем используются для настройки объекта environment
, который использует программа.
Структура, которую я имею в виду, это:
![0sgq4.png]()
Следуя сплошным строкам, это означает, что GUI создает файл XML, содержащий ту же информацию, что и параметры оболочки /cmdline, которая затем используется для настройки опции environment
.
Дело в том, что я не совсем уверен, что лучший способ для работы (откуда пунктирные линии, обозначающие альтернативные структуры), и я также не знаю, является ли здесь правильный выбор XML.
В соответствии с этим части программы, которые устанавливают объект environment
из options
, расположены в тех же методах, что и части, которые используют environment
для получения результатов. Поэтому было бы проще реализовать что-то, что передавало аргументы shell/cmdline непосредственно в программу, чем было бы для реализации структуры, в которой информация передавалась как XML файл. Я, конечно же, не хочу создавать XML файл, а затем переводить его в параметры оболочки и передавать их в программу, но для GUI может возникнуть больше смысла генерировать собственные параметры оболочки, а не создавать XML.
Основное преимущество использования XML файла, насколько я могу судить, заключается в том, что он упрощает работу будущих разработчиков, поскольку они могут использовать существующие библиотеки для создания XML файлов, а не беспокоиться о получении синтаксиса -a opt1 -b opt2 -c opt3 [...]
правильно.
С другой стороны, я слышал, что попытка создать собственный XML-язык не воспринимается легкомысленно (хотя программа поскольку он хранит данные в файлах XML без DTD или даже схемы, насколько я могу судить).
Является ли мой подход более или менее правильным? Или я использую совершенно неприемлемые инструменты для работы, которую я пытаюсь сделать?
Ответы
Ответ 1
В XML-подходе вы будете использовать пользовательские параметры, создать XML, передать его в основную программу, проанализировать XML и извлечь значения для установки среды. Эти усилия будут слишком велики, если вы не передадите параметры из одного процесса в другой процесс или через провод (даже в этом случае вы также можете использовать json)
Если мы говорим об одном процессе, в котором эти параметры передаются либо через GUI, либо в командной строке, мы можем просто инкапсулировать эти параметры в объект Java, заполнить его с помощью командной строки/графического интерфейса и передать его в основную программу, Например
Командная строка или графический интерфейс → Заполнить объект EnvironmentOptions
→ Основная программа
Чтобы обеспечить абстракцию, вы можете создать интерфейс IEnvironmentOption
и использовать его для установки необходимых свойств.
interface IEnvironmentOption {
public static final String OPTION_NAME = "-t";
public void setOption(String name, String value);
public String getOption(String name);
}
class EnvironmentOptions implements IEnvironmentOption {
private Properties envProperties;
@Override
public void setOption(String name, String value) {
envProperties.setProperty(name, value);
}
@Override
public String getOption(String name) {
return envProperties.getProperty(name);
}
}
Ответ 2
Кажется, у вас есть солидный план. Это довольно распространенная парадигма для загрузки параметров из аргументов командной строки и/или файла конфигурации. Нет проблем с использованием XML, но JSON и YAML - это пара альтернатив синтаксису синтаксиса, который будет работать так же хорошо.
Java уже имеет Properties и Preferences, которые могут быть использованы для этого. Вы должны взглянуть на них, прежде чем изобретать колесо.