Jakie są plusy i minusy używania XML do przesyłania danych w tym programie Java?

Question

Zostałem poproszony o napisanie GUI dla istniejącego programu powłoki/cmdline napisanego w Javie i chcę stworzyć warstwę abstrakcji pomiędzy GUI i oryginalnym programem, który ułatwia dodanie innego GUI (WWW interfejs, na przykład zamiast aplikacji komputerowej). W tej chwili, struktura programu jest następująca:.

opcje wiersza polecenia są natychmiast przełożyło się na hashtable Java (przy opcji takich jak -f opt do mieszania "-f=>opt" Opcje te są następnie wykorzystywane . do utworzenia obiektu environment, który wykorzystuje program

struktura mam na myśli to:

Po linii ciągłej oznacza to, że GUI tworzy plik XML zawierający te same informacje, co opcje powłoki/polecenia cmdline, a następnie służy do ustawienia opcji environment.

Chodzi o to, że nie jestem do końca pewien, czy to najlepszy sposób na działanie (skąd linie przerywane oznaczają alternatywne struktury), a także nie wiem, czy XML jest tu właściwym wyborem.

W obecnej wersji części programu, które ustawiają obiekt environment z options, są umieszczone w tych samych metodach co części, które używają environment, aby uzyskać wyniki. Więc łatwiej byłoby zaimplementować coś, co podawałoby argumenty powłoki/polecenia cmdline bezpośrednio do programu, niż zaimplementowałoby strukturę, w której informacja była przekazywana jako plik XML. Na pewno nie chcę tworzyć pliku XML, a następnie tłumaczyć go na opcje powłoki i przenosić je do programu, ale może to mieć więcej sensu dla GUI do generowania samych opcji powłoki niż tworzenia XML.

Główną zaletą używania pliku XML, o ile widzę, jest to, że ułatwia on przyszłym programistom korzystanie z istniejących bibliotek do tworzenia plików XML, a nie martwienie się o uzyskanie prawidłowej składni -a opt1 -b opt2 -c opt3 [...] .

Z drugiej strony, słyszałem, że próba stworzenia własnego języka XML to not to be taken lightly (chociaż program, w którym stoi, przechowuje dane w plikach XML bez DTD lub nawet schematu, o ile wiem).

Czy moje podejście jest mniej lub bardziej prawidłowe? Czy używam całkowicie nieodpowiednich narzędzi do pracy, którą próbuję wykonać?

Answer 1

Podejście XML polegało na wybraniu opcji użytkownika, utworzeniu kodu XML, przesłaniu go do programu głównego, przeanalizowaniu kodu XML i wyodrębnieniu wartości w celu ustawienia środowiska.Wysiłki te będą zbyt duże, chyba że przekazujesz opcje z jednego procesu do innego procesu lub przez przewód (nawet w tym przypadku możesz użyć json też)

Jeśli mówimy o pojedynczym procesie, w którym te opcje są przekazywane albo poprzez GUI lub wiersz poleceń, możemy po prostu zamknąć te parametry w obiekcie Java, wypełnić go za pomocą wiersza poleceń/GUI i przekazać go do programu głównego. Na przykład linii poleceń lub GUI -> Wypełnianie EnvironmentOptions obiektu -> program główny

I dostarczenie wymagać abstrakcję, można utworzyć interfejs powiedzieć IEnvironmentOption i używać go ustawić wymagane właściwości.

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); 
    } 
} 

Answer 2

Wygląda na to, że masz solidny plan. Jest dość powszechnym paradygmatem ładowanie opcji z argumentów linii poleceń i/lub pliku konfiguracyjnego. Nie ma problemu z używaniem XML, ale JSON i YAML to kilka alternatyw ze składnią terser, która zadziała równie dobrze.

Java ma już Properties i Preferences, za pomocą których można to zrobić. Powinieneś rzucić okiem na te przed wynalezieniem koła.