HMVC: il modello a più livelli per lo sviluppo di livelli client forti

Il compito di progettare e sviluppare il livello client di un'architettura Web a più livelli spesso sfida gli sviluppatori. Ciò è particolarmente vero nel mondo Web, dove l'enorme varietà di server, piattaforme di distribuzione e protocolli trasforma la sfida in un mal di testa. Un architetto di livello client deve rispondere a una serie di domande:

  • Come devo strutturare la mia GUI?
  • Come interagiranno gli utenti con la mia GUI?
  • Come devo separare i formati di dati lato server / trasporto dalla mia GUI?
  • Come devo fornire meccanismi validi per la gestione degli eventi, i flussi delle applicazioni e il controllo dei widget?

Per comprendere alcuni di questi problemi chiave, dobbiamo distinguere tra il livello di presentazione (o livello client ) e il livello della GUI . Il livello della GUI si occupa di un piccolo sottoinsieme dell'intero livello di presentazione, vale a dire i widget dell'interfaccia utente e gli effetti immediati delle azioni dell'utente , ad esempio a JTextFielde relativo ActionListener. Il livello di presentazione deve gestire i flussi delle applicazioni e l'interazione con il server oltre a fornire servizi GUI. I termini livello di presentazione e livello client vengono usati in modo intercambiabile in questo articolo.

Approccio basato su framework

Per mitigare il rischio associato alla creazione di un solido livello client, gli sviluppatori hanno prodotto diversi framework e modelli di progettazione con diversi gradi di successo. Il paradigma Model-View-Controller (MVC) rimane uno dei modelli più duraturi. Tuttavia, il tradizionale ambito MVC non è all'altezza quando si tratta del controllo degli elementi GUI (widget). MVC non gestisce le complessità della gestione dei dati, della gestione degli eventi e dei flussi delle applicazioni. Come adattamento della triade MVC, il paradigma HMVC - Hierarchical-Model-View-Controller - cerca di risolvere alcuni dei problemi sopra menzionati. Abbiamo sviluppato questo modello nel corso del nostro lavoro sul campo. HMVC fornisce una metodologia di progettazione a strati potente ma di facile comprensione per lo sviluppo di un livello di presentazione completo.Mentre MVC fornisce un framework efficiente per lo sviluppo dell'interazione GUI, HMVC lo scala all'intero livello client. Alcuni vantaggi chiave di un'architettura a più livelli basata sulla responsabilità includono:

  • Comunicazione intralayer definita e isolamento dai livelli superiori
  • Comunicazione tra gli strati definita con accoppiamento minimo
  • Localizzazione dell'esposizione a codice di terze parti

Questo articolo esplora l'applicazione del modello di progettazione HMVC nello sviluppo di un'infrastruttura di livello client basata su Java.

Nota : l'intero codice sorgente di questo articolo può essere scaricato come file zip dalla sezione Risorse di seguito.

Controller vista modello - MVC

Gli sviluppatori utilizzano principalmente MVC in Smalltalk per l'implementazione di oggetti GUI. Numerose librerie di classi GUI e framework applicativi hanno riutilizzato e adottato il modello. Poiché il paradigma MVC offre un mezzo elegante e semplice per risolvere i problemi relativi all'interfaccia utente in modo orientato agli oggetti, la sua popolarità è giustificata. MVC fornisce ruoli e responsabilità chiaramente definiti per i suoi tre elementi costitutivi: modello, visualizzazione e controller. La vista gestisce il layout dello schermo, ovvero ciò con cui l'utente interagisce e vede sullo schermo. Il modello rappresenta i dati alla base dell'oggetto, ad esempio lo stato on-off di una casella di controllo o la stringa di testo da un campo di testo. Gli eventi provocano la modifica dei dati nel modello. Il controller determina il modo in cui l'utente interagisce con la vista sotto forma di comandi.

MVC a strati - HMVC

Il modello HMVC scompone il livello client in una gerarchia di livelli MVC padre-figlio. L'applicazione ripetitiva di questo modello consente un'architettura strutturata a livello di client, come mostrato nella Figura 1.

L'approccio MVC a più livelli assembla un livello client abbastanza complesso. Alcuni dei principali vantaggi dell'utilizzo di HMVC rivelano i vantaggi dell'orientamento agli oggetti. Un'architettura stratificata in modo ottimale:

  • Riduce le dipendenze tra parti disparate del programma
  • Incoraggia il riutilizzo di codice, componenti e moduli
  • Aumenta l'estensibilità facilitando la manutenibilità

Usa HMVC per progettare un'architettura di livello client

Sebbene tu possa trovare il compito scoraggiante, puoi gestire efficacemente lo sviluppo di un livello di presentazione per un'applicazione incorporando lo sviluppo intelligente nella tua strategia, ovvero utilizzando un modello robusto e scalabile che può ridurre parte del rischio e fornire un base di progettazione già pronta su cui costruire.

Ci sono tre aspetti chiave dello sviluppo a livello di client:

  • Codice layout GUI : layout widget e aspetto dello schermo
  • Codice funzione GUI : convalide e acquisizione di eventi utente
  • Codice logico dell'applicazione : flussi dell'app, navigazione e interazione con il server

Il modello di progettazione HMVC incoraggia la scomposizione del livello client in livelli distinti e sviluppati per l'implementazione di GUI e servizi applicativi. Un'architettura basata su modelli porta alla standardizzazione; il modello HMVC standardizza il livello di presentazione (servizio-utente) delle applicazioni Web. La standardizzazione nel livello di presentazione aiuta a contribuire a:

  • Coerenza dell'interfaccia utente : il framework divide un'entità visiva (vista) in riquadri con responsabilità e funzionalità specifiche e coerenti.
  • Interazione standardizzata : l'interazione tra i vari sottocomponenti all'interno del livello di presentazione è chiaramente definita, fornendo classi di base personalizzabili.
  • Codice gestibile : l'utilizzo di un modello produce codice gestibile che fornisce una base di codice flessibile ed estensibile per lo sviluppo di applicazioni.
  • Supporto del flusso di applicazioni: il framework struttura il servizio di presentazione in livelli distinti e fornisce la comunicazione tra i livelli e tra i livelli. Tale struttura offre un modo solido e ordinato per implementare la logica e il flusso dell'applicazione.

Principi di progettazione

Il modello HMVC fornisce una chiara definizione delle responsabilità tra i diversi componenti e strati. È possibile utilizzare modelli di progettazione standard (fabbriche astratte, composito, catena di responsabilità, facciata, ecc.) Per fornire un design stabile.

La Figura 2 illustra alcuni livelli e componenti chiave del pattern HMVC. I livelli orizzontali specificano la gerarchia all'interno dell'applicazione; le sezioni verticali si riferiscono ai componenti della triade MVC. All'interno di un livello, il controller ha la responsabilità generale di gestire il modello e visualizzare i componenti. Ad esempio, il controller GUIFrame controlla il modello GUIFrame e il GUIFrame (la vista). Le linee tratteggiate tra modello, controller e vista all'interno di un livello indicano interfacce chiaramente definite per la comunicazione. Questa interazione si ottiene tramite AppEvents. Per la comunicazione intralayer, esiste una gerarchia controllore padre-figlio e tutte le comunicazioni intralayer possono essere instradate solo attraverso questo percorso. I responsabili del trattamento interagiscono tramite AppEvents.

Visualizza

Un utente interagisce con la vista, la parte visibile dell'applicazione. HMVC astrae le viste a diversi livelli per fornire un metodo pulito per la progettazione della GUI. Al livello più alto c'è un GUIContainer, con il suo controller associato. Il contenitore contiene essenzialmente viste potenzialmente multiple, chiamate GUIFrame (s); ogni GUIFrame è un'entità visiva con cui un utente interagisce. Il framework definisce un GUIFrame come composto da più sottoparti, ovvero un menu GUIPane, un Navigation GUIPane, Status GUIPane e un Content GUIPane centrale (vedere la Figura 3). Nelle applicazioni Web più comuni, gli sviluppatori di solito si aspettano che più GUIFrame siano improbabili; principalmente, è il contenuto GUIPane che deve cambiare. L'area Content GUIPane è considerata la parte più importante del GUIFrame; è qui che si verifica la maggior parte dell'interazione dell'utente.Il framework presume che il controllo efficiente di più Content GUIPane sarà sufficiente per fornire una parte molto ampia dell'esperienza utente.

La Figura 3 illustra un tipico frontend GUI. Si divide in più parti (cioè GUIPanes). Possiamo applicare la triade MVC a ciascuno dei riquadri di composizione e stabilire una gerarchia, con il GUIFrame composto da Menu, Stato, Nav e GUIPane del contenuto. A seconda della complessità del codice all'interno di ciascun componente, possiamo o meno assegnare un controller e un modello indipendenti a un GUIPane. Ad esempio, a causa della sua semplicità e della mancanza di una reale necessità di un controllo sofisticato, non è necessario che lo Status GUIPane abbia un proprio controller; possiamo scegliere di far eseguire al controller GUIFrame lo Status GUIPane. Tuttavia, poiché Content GUIPane è un'area di attività importante, potremmo assegnargli un controller e un modello separati. Basato sulla triade MVC, un GUIFrame ha il suo controller associato e il modello del titolare dei dati,così come il contenuto GUIPane. Il livello GUIFrame ha GUIContainer come triade padre. Il GUIContainer è una parte invisibile dell'architettura; può potenzialmente contenere più GUIFrame.

Un aspetto cruciale del design è l'isolamento del codice specifico di Swing, ovvero i componenti Swing e i loro ascoltatori (fare riferimento alla Figura 2), all'interno del gradino più basso della gerarchia. A titolo illustrativo, i widget Swing compongono principalmente il Content GUIPane. Questa non è una limitazione di progettazione; un Nav GUIPane potrebbe anche avere un componente Swing come, ad esempio, un JTree. Pertanto, il Content GUIPane è anche responsabile del catering per eventi Swing come ActionEvents. Allo stesso modo, un ActionEventgenerato facendo clic su JMenuItemall'interno del Menu GUIPane viene ascoltato dal Menu GUIPane stesso. Pertanto, un GUIPane funge da ascoltatore per gli eventi Swing. Il GUIPane interessato può successivamente richiedere un ulteriore servizio dal suo controller utilizzando eventi a livello di applicazione. Ciò consente la localizzazione del codice specifico di Swing.

Controller

Il controller utilizza il modello per coordinare gli effetti degli eventi utente sulla vista con il modello; si rivolge anche al flusso logico. HMVC definisce i livelli all'interno della GUI e fornisce il controllo distribuito degli eventi attraverso una gerarchia di controller padre-figlio. All'interno di un livello, il controller è il comandante supremo, orchestrando i flussi dell'applicazione e le risposte agli eventi dell'utente. Il modello di progettazione della catena di responsabilità implementa i controller, in cui trasmettono eventi a cui non possono soddisfare.

Ad esempio, se, come risultato del clic su un pulsante all'interno di una Content GUIPane, il Menu GUIPane deve cambiare, allora ActionEventverrebbe intercettato dal Content GUIPane stesso (poiché è l'ascoltatore per eventi Swing / AWT). Il ContentGUIPane effettuerebbe successivamente una richiesta di navigazione al controller ContentGUIPane, che a sua volta la passerebbe al controller principale, il controller GUIFrame. Ciò risulta perché la modifica nel Menu GUIPane può essere effettuata solo a un livello superiore, poiché Content GUIPane e Menu GUIPane sono allo stesso livello nella gerarchia (sono entrambi contenuti in un GUIFrame).

Relazione genitore-figlio

Viene stabilita una relazione genitore-figlio assoluta e chiaramente definita tra un controller GUIContainer al livello più alto, o padre, e il suo figlio, il controller GUIFrame. Allo stesso modo, esiste una relazione padre-figlio tra un controller GUIFrame e un controller GUIContent Pane. Il controller all'interno di ogni livello è responsabile solo delle azioni limitate alla sua sfera di influenza, ovvero il modello e la vista a quel livello. Per tutti gli altri servizi, il controller deve trasferire le azioni al suo genitore.

Comunicazione

Se un controllore non è in grado di gestire il suo evento, il pattern Catena di responsabilità segnala al controllore di passare l'evento al suo genitore. I controller comunicano tra loro tramite AppEvents, che in genere possono essere eventi di navigazione, eventi di richiesta dati o eventi di stato. Gli eventi di navigazione sono in genere quelli che cambiano l'aspetto della visualizzazione. Ad esempio, se si fa clic su JMenuItemall'interno del menu GUIPane, che sostituisce il Content GUIPane attivo, l'evento di navigazione apporterebbe la modifica. Lo sviluppatore dell'applicazione avrebbe bisogno di identificare questi eventi e creare alcuni stereotipi di base.

I controllori possono anche comunicare tramite eventi di dati. Se un Content GUIPane deve visualizzare i dati in alcuni JTextFieldoggetti, il Content GUIPane creerà un evento dati. Il Content GUIPane lo passerebbe quindi al suo controller, il quale, dopo aver determinato che si tratta di un evento dati, lo delegherebbe al modello associato. Il modello successivamente passerebbe una richiesta di aggiornamento al Content GUIPane, che fornirebbe un percorso di comunicazione pulito e ben definito.

Responsabilità

Il titolare del trattamento ha molteplici responsabilità; deve rispondere agli eventi di navigazione a livello di applicazione e agli eventi di richiesta di dati, ad esempio. In risposta agli eventi di navigazione, un controller fornisce la logica del flusso dell'applicazione, ad esempio cambiando schermate o disabilitando / abilitando le opzioni. Per gli eventi di richiesta dati, il controller delega la richiesta a un oggetto modello associato.

Modello

Le entità di visualizzazione come GUIContainer, GUIFrame e GUIContent Riquadro hanno modelli associati. HMVC fornisce modelli a ogni livello della gerarchia, ma spetta al progettista dell'applicazione implementarli effettivamente. Il modello GUIContainer generalmente contiene dati o informazioni che interessano l'intera applicazione, mentre il modello GUIFrame contiene informazioni relative solo allo stato di un GUIFrame. Il modello contiene o contiene gli oggetti dati che devono essere visualizzati o elaborati in una vista. In genere, il modello riceve una richiesta del servizio dati delegato dal controller, recupera i dati e notifica alla vista associata la disponibilità di nuovi dati.