Qual è il tuo consiglio per l'architettura di applicazioni GWT? MVC, MVP o soluzione di messaggistica personalizzata?

Question

Ho appena iniziato un nuovo progetto GWT per un cliente e sono interessato a sentire l'esperienza delle persone con varie architetture GWT MVC. In un recente progetto, ho utilizzato sia GXT MVC , sia una soluzione di messaggistica personalizzata (basata su MQ di Appcelerator ). GXT MVC ha funzionato bene, ma sembrava eccessivo per GWT ed è stato difficile lavorare con la cronologia del browser. Ho sentito di PureMVC e GWTiger , ma non li ha mai usati. La nostra soluzione MQ personalizzata ha funzionato abbastanza bene, ma ha reso difficile testare i componenti con JUnit.

Inoltre, ho sentito che Google Wave (un'applicazione GWT) è scritta usando un modello Model-View-Presenter. Una applicazione MVP di esempio è stata recentemente pubblicata, ma guardando il codice, non sembra così intuitivo.

Se dovessi creare una nuova applicazione GWT, quale architettura useresti? Quali sono i pro e i contro della tua scelta?

Grazie,

Matt

Answer 1

Vale la pena notare che Google ha finalmente scritto un tutorial per la progettazione usando l'architettura mvp. Chiarisce molti elementi del discorso I / O di Google sopra elencato. Dai un'occhiata: https://developers.google.com/web-toolkit/articles / mvp-architettura

Answer 2

Sono contento che questa domanda sia stata posta, perché GWT desperatley ha bisogno di un modo simile a un binario per strutturare un'applicazione. Un approccio semplice basato sulle migliori pratiche che funzionerà per il 90% di tutti i casi d'uso e consente una testabilità super facile.

Negli ultimi anni ho usato la mia implementazione di MVP con una visione molto passiva che si asservisce a tutto ciò che il Presentatore gli dice di fare.

La mia soluzione consisteva in:

• un'interfaccia per widget che definisce i metodi per controllare l'aspetto visivo
• una classe di implementazione che può essere un composito o utilizzare una libreria di widget esterna
• un presentatore centrale per uno schermo che ospita N visualizzazioni costituite da widget M
• un modello centrale per schermata che contiene i dati associati all'attuale aspetto visivo
• classi di listener generiche come " SourcesAddEvents [CustomerDTO] " (l'editor non ama i simboli reali per i generici java qui, quindi ho usato le parentesi quadre), perché altrimenti avrai molte stesse interfacce che differiscono solo per il tipo

Le viste ottengono un riferimento al presentatore come parametro del costruttore, in modo che possano inizializzare i loro eventi con il presentatore. Il relatore gestirà quegli eventi e notificherà altri widget / viste e chiamerà gwt-rpc che in caso di successo inserisce il suo risultato nel modello. Il modello ha una tipica proprietà [quot [String]] name = .... " meccanismo del listener di modifica delle proprietà registrato con il presentatore in modo che l'aggiornamento di un modello da una richiesta gwt-rpc vada a tutte le viste / tutti i widget interessati.

Con questa valutazione ho ottenuto una testabilità molto semplice con EasyMock per le mie AsynInterfaces. Ho anche avuto la possibilità di scambiare facilmente l'implementazione di una vista / widget, perché tutto ciò che dovevo riscrivere era il codice che notificava al presentatore di qualche evento, indipendentemente dal widget sottostante (Pulsante, Link, ecc.)

Problemi con il mio approccio:

• La mia attuale implementazione rende difficile sincronizzare i valori dei dati tra i modelli centrali di schermi diversi. Supponi di avere una schermata che visualizza un insieme di categorie e un'altra schermata che ti consente di aggiungere / modificare tali elementi. Attualmente è molto difficile propagare quegli eventi di cambiamento oltre i confini delle schermate, perché i valori sono memorizzati nella cache in quei modelli ed è difficile scoprire se alcune cose sono sporche (sarebbe stato facile in un web1.0-html tradizionale -dumb-terminal tipo di scenario con cache dichiarativa sul lato server).
• I parametri del costruttore delle viste consentono di eseguire test semplicissimi, ma senza un solido framework di dipendenza-iniezione, all'interno del "onModuleLoad () " ;. sarà presente un codice di configurazione / configurazione BRUTTO. Quando ho iniziato questo, non ero a conoscenza di Google GIN, quindi quando refactoring la mia app, la userò per sbarazzarmi di questa piastra di cottura. Un esempio interessante qui è "HigherLower" gioco all'interno del GIN-Trunk.
• La cronologia non è stata eseguita correttamente la prima volta, quindi è difficile spostarsi da una parte della mia app a un'altra. Il mio approccio non è a conoscenza della storia, che è una grave recessione.

Le mie soluzioni a questi problemi:

• Usa GIN per rimuovere la piastra di installazione che è difficile da mantenere
• Mentre passi da Gwt-Ext a GXT, usa il suo framework MVC come EventBus per collegare / scollegare schermi modulari, per evitare i problemi di cache / sincronizzazione
• Pensa a una sorta di "Posizionamento" -Astrazione come Ray Ryan descritta nel suo discorso all'I / O 09, che colma l'approccio Event-Gap tra GXT-MVC e GWTs-Hitory approccio
• Utilizza MVP per i widget per isolare l'accesso ai dati

Sommario:

Non credo che si possa usare un singolo "MVP" approccio per un'intera app. Uno ha sicuramente bisogno di cronologia per la navigazione delle app, un eventbus come GXT-MVC per collegare / scollegare schermate e MVP per consentire un facile test di

Answer 3

Ecco una recente presentazione di Google IO su che progetta la tua applicazione GWT .

Enjoy.

-JP

Answer 4

Se sei interessato a utilizzare l'architettura MVP, potresti dare un'occhiata a GWTP: http://code.google.com/p/gwt-platform/ . È un framework MVP open source su cui sto lavorando, che supporta molte belle funzionalità di GWT, tra cui la suddivisione del codice e la gestione della cronologia, con una semplice API basata su annotazioni. È piuttosto recente, ma è già in uso in numerosi progetti.

Answer 5

Dovresti dare un'occhiata a Portlet GWT . Abbiamo sviluppato il Portlet Framework GWT mentre lavoravamo su una grande applicazione del portale delle risorse umane ed è ora gratuito e open source. Dal sito Web dei portlet GWT (ospitato su codice Google):

Il modello di programmazione è in qualche modo simile alla scrittura di portlet JSR168 per un server portale (Liferay, JBoss Portal ecc.). Il "portale" è l'applicazione creata utilizzando il framework dei portlet GWT come libreria. La funzionalità dell'applicazione è sviluppata come portlet liberamente accoppiati ciascuno con un DataProvider lato server opzionale.

Ogni Portlet sa come esternalizzare il suo stato in una sottoclasse PortletFactory serializzabile (momento / DTO / modello di fabbrica) rendendo possibili importanti funzionalità:

• Le operazioni CRUD sono gestite da un singolo RPC GWT per tutti i portlet
• Il layout dei Portlet su una "pagina" può essere rappresentato come un albero di WidgetFactory (un'interfaccia implementata da PortletFactory)
• Gli alberi di WidgetFactory possono essere serializzati e sottoposti a marshalling da / verso XML sul server, per archiviare i layout della GUI (o "quotare le pagine") in file di pagine XML

Altre caratteristiche importanti del framework sono elencate di seguito:

• Le pagine possono essere modificate nel browser in fase di esecuzione (da sviluppatori e / o utenti) utilizzando l'editor del layout del framework
• I portlet sono posizionati in modo assoluto, quindi possono utilizzare le aree di scorrimento
• I portlet sono configurabili, indicano quando sono occupati nel caricamento automatico dello "spinner di caricamento" visualizzare e può essere ingrandito
• Widget a tema tra cui una finestra di dialogo in stile, una sostituzione di pulsanti in stile CSS, piccoli pulsanti degli strumenti e un menu guidato da un modello HTML

I portlet GWT sono implementati nel codice Java e non includono alcuna libreria Javascript esterna. Non impone alcun framework lato server (ad esempio Spring o J2EE) ma è progettato per funzionare bene insieme a tali framework.