Ho una libreria che definisce i messaggi. Nella mia particolare istanza, è un codice generato automaticamente da un XSD che utilizza JAXB (Java). I messaggi possono essere molto complessi, con alcuni membri come oggetti e quegli oggetti contenenti altri oggetti. Gli oggetti sono sia classi che enumerazioni. La libreria è un singolo file JAR senza dipendenze, indicato come componente riutilizzabile per le applicazioni Java. L'idea è che qualsiasi applicazione Java che ha bisogno di inviare o ricevere questi messaggi utilizzerà questa libreria per farlo. Al momento, sono definiti 10 messaggi, ma esiste un numero elevato di tipi di dati (classi ed enumerazioni) definiti anche nella libreria contenuti nei messaggi.
L'esigenza immediata è per un'applicazione grafica che consente all'utente di costruire i messaggi nel formato specificato e quindi pubblicarli in modo appropriato tramite una connessione di rete. Ciò significa che l'utente sarebbe in grado di creare i 10 messaggi e popolare i vari campi che vi entrano. Il risultato è una stringa XML conforme allo schema che può essere pubblicata in un'applicazione di ascolto. L'applicazione di ascolto genera anche messaggi che sono anche definiti nell'XSD e nella libreria in base allo schema e che devono essere ricevuti.
È auspicabile anche essere in grado di creare una versione da riga di comando di questa applicazione che possa essere sottoposta a script. Questa versione della riga di comando non è ben definita, ma potrebbe essere interattiva (con prompt) o semplicemente argomento della riga di comando guidata per pubblicare i messaggi.
Quale sarebbe l'approccio migliore per creare la mia applicazione intorno a questa libreria?
Mi vengono in mente due approcci:
Il primo approccio è un wrapper attorno alla libreria che fa parte della build dell'applicazione. Questo wrapper sarebbe quasi una duplicazione della libreria JAXB, ma non richiamerebbe gli oggetti dati generati fino a quando richiesto. Sarebbe un builder che fornirebbe anche una convalida e forse una semplificazione interfaccia per alcuni dei componenti dei messaggi. Questo potrebbe essere utile, dal momento che la libreria JAXB non ha un concetto di convalida fino a quando gli elementi non vengono smistati. Anche se puoi marshall a un gestore predefinito al contrario del tuo formato di output come un file o un flusso, ma ciò non sembra molto utile poiché i messaggi che ricevi dagli errori di convalida non sono esattamente user-friendly. In questo approccio, la GUI, l'interfaccia utente testuale e l'interfaccia della riga di comando interagirebbero tutti con questo modello di dati dell'applicazione.
Il secondo approccio sarebbe quello di organizzare le mie interfacce utente in diversi pacchetti. I pacchetti della GUI fornirebbero elementi dell'interfaccia utente che corrispondono ai campi di ciascun messaggio. Le regole di convalida dall'XSD sarebbero applicate come regole di convalida a ciascun campo, usando cose come InputVerifier s , caselle combinate, caselle di controllo e altri elementi che impediscono i dati non validi prima che vengano persino passati al modello dati. L'interfaccia utente del testo fornisce essenzialmente la stessa cosa, ma leggendo e scrivendo sullo standard input, output e flussi di errore. Sospetto che in queste implementazioni le classi di input corrispondessero alle classi del modello di dati da 1 a 1: ciascuna classe di input sarebbe responsabile della raccolta e della convalida degli input dell'utente necessari per costruire un singolo elemento di dati (una classe nel modello di dati fornito dalla libreria JAXB). Ho il sospetto che l'interfaccia utente grafica e la GUI possano condividere le classi di base o le interfacce che ciascuna delle classi UI può ereditare per consentire che vengano passate nello stesso controller per leggere e produrre l'oggetto appropriato dal modello di dati. Un'interfaccia della riga di comando probabilmente userebbe un parser per gli argomenti della riga di comando per raccogliere l'input, assicurarsi che ci sia tutto , convalidare tutti i campi e quindi eseguire le trasmissioni o le ricezioni. Sarebbe implementato in modo molto diverso rispetto alle interfacce utente interattive.
Personalmente mi sto appoggiando al secondo approccio, ma sospetto che ci possa essere un'altra strategia migliore là fuori.