Vaadin: Design patterns

Question

Attualmente sto lavorando su tre applicazioni Vaadin e mi sento davvero come se mi mancasse qualcosa. Prima lavoravo con Spring MVC, in cui l'architettura è chiara e disaccoppiata, si iniettano servizi ai controller e non si accoppiano il controller all'IU e così via.

Ora in Vaadin questa è un'altra storia. Quindi, se ci sono gli specialisti Vaadin là fuori, mi permetta di rivolgerle alcune domande:

Domanda 1:

• E 'OK per iniettare servizi (o DAO) direttamente ai componenti dell'interfaccia utente?
• Esempio: il componente responsabile della visualizzazione dei contatti nell'applicazione di posta elettronica (ContactWidget, basato sul VerticalLayout con collegamenti) deve visualizzare i contatti. Va bene iniettare contactRepository direttamente su questo elemento dell'interfaccia utente?

Domanda 2:

• di riferimento per l'applicazione principale viene passato alla quantità enorme di componentistica di interfaccia utente, in quanto molti componenti dell'interfaccia utente ha bisogno di accedere ad alcuni dati globali o richiamare i metodi globali sulla principale classe di applicazione
• Esempio: Il componente popup ha Pulsante che apre una nuova finestra, che dovrebbe essere figlio della finestra principale dell'applicazione. Pertanto il componente popup deve avere un riferimento all'applicazione principale.

Domanda 3:

• dipendenze tra i componenti dell'interfaccia utente può ottenere abbastanza selvaggio. Probabilmente non c'è molto da fare qui, ma a volte non sembra che questa finestra dipenda da questa lista che dipende da quel popup ... hai l'idea, sembra strettamente accoppiata a me

I'd piace imparare il più possibile sul buon design con Vaadin prima che il mio codice passi a Spaghetti, quindi qualsiasi suggerimento, esperienza e buone pratiche sarebbe apprezzato.

Answer 1

Abbiamo avuto molta fortuna con il pattern MVVM (alias Fowler's PresentationModel). I suoi documenti sono un po 'vecchi, ma un buon punto di partenza.

Dopo aver letto questo, le mie risposte possono avere più senso

1. No. Iniettare i propri servizi nel vostro ViewModel. Il ViewModel sarà una facciata (e può incapsulare gli adattatori, i decoratori, le cache e qualsiasi altro modello che decidi tu sia necessario)

2. Non ho visto una domanda qui, ma abbiamo una situazione simile a quella che sei descrivendo. Usiamo Eventbus di Guava per comunicare tra componenti disaccoppiati.In questo modo, se devi aprire una nuova finestra, puoi: eventBus.post(new NewWindowRequest(theComponent)) E la tua applicazione principale può essere abbonata allo stesso evento, quindi aprire la finestra.

3. MVVM e l'uso prudente di EventBus possono essere d'aiuto. Inoltre, Vaadin's BeanItem e ObjectProperty possono essere utilizzati per propagare le modifiche, poiché fanno parte del modello di osservatore incorporato/associazione dati di Vaadin.

Recentemente ho fatto un presentation on MVC vs MVP vs MVVM. Il codice di esempio può aiutarti a capire il passaggio da MVC a MVVM. È scritto in JavaScript, ma è abbastanza semplice che credo che chiunque possa seguirlo. Accolgo con favore qualsiasi feedback tu possa avere.

Answer 2

Vaadin è un ottimo software e sicuramente non dovresti finire con il codice Spaghetti. Ad ogni modo, tutto dipende da te.

Risposta 1

No, non lo è. L'accoppiamento stretto non è valido indipendentemente dal framework utilizzato. Il tuo esempio (ContactWidget) descrive un'implementazione personalizzata di un elenco. Può essere visualizzato come una tabella con o senza ulteriori informazioni. Userò un esempio di tabella perché è più complesso e più flessibile (è possibile creare l'intera applicazione con componenti avanzati della tabella e un'associazione corretta dei dati).

Vaadin definisce il modello di dati avanzato seguendo il modello MVC noto. Esistono tre livelli nidificati: contenitore, oggetto, proprietà (vengono definiti anche i visualizzatori di proprietà e gli editor). Il libro di Vaadin suggerisce una buona analogia: applicazione per fogli di calcolo. Quindi contenitore, oggetto e proprietà corrisponderanno a tabella, riga e cella. Facile da immaginare: facile da capire. Infine, ItemContainer rivelerà la sua natura e capirai che questo è il contratto chiave per qualsiasi buona e flessibile architettura basata su Vaadin. Vorrei suggerire di guardare attraverso Vaadin libro, per avere tutti gli altri dettagli:

• https://vaadin.com/book/-/page/datamodel.html
• https://vaadin.com/book/-/page/datamodel.container.html

È possibile anche rivedere implementazione contenitore dietro ogni addon PagedTable per ottenere anche una migliore comprensione. Inizia anche con ArrayContainer https://vaadin.com/directory#addon/array-container, semplificherà molto per te.

Risposta 2

Passando riferimento principale non sembra essere una buona soluzione. Si è notato che l'istanza dell'applicazione rappresenta la sessione ma sarà molto meglio definire un tipo di contratto SessionContext (che può ancora essere implementato dall'applicazione). È possibile definire un metodo statico per fornire un accesso trasparente all'istanza SessionContext pertinente. Sotto il cofano può usare la variabile ThreadLocal http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html In tal modo si eliminerà tutti i parametri parassiti che passano.

Risposta 3

Progettazione della gerarchia con una grande cura. Non attivare il ridisegno, utilizzare invece Refresher. Tieni d'occhio l'intera architettura.

Infine, Vaadin è semplice da usare, quindi sentitevi liberi di fare piccoli PoC e demo prima di cambiare il codice base principale.

Come era suggerisco si può anche provare MVVM https://vaadin.com/directory#addon/bambi-mvvm