Non ho una soluzione pronta per il tuo problema e non credo che ce ne sia uno. Spiegherò solo la soluzione che uso e ciò che prenderei in considerazione nel tuo caso.
Nella mia organizzazione, il nostro approccio è quello di separare le nostre applicazioni in un back-end Grails e un front-end in Flex. La ragione è che disponiamo di molti componenti Flex pronti all'uso che richiederebbero troppo tempo per essere implementati utilizzando tecnologie web pure, ma non è questo il punto.
La creazione di un back-end REST in Grails è rapida, poiché le viste sono impalcature quando appropriato, i controller sono semplici e la convalida dell'input è notevolmente semplificata dai vincoli di Dominio.
Lo svantaggio di questa divisione è che la definizione di oggetti dominio deve essere duplicata nel front-end. Potresti includere la convalida degli oggetti nel front-end o meno, ma se li ometti, avrà un'influenza sulla reattività dell'interfaccia utente (richieste al back-end REST nelle chiamate AJAX per la convalida in tempo reale per ottenere gli errori) . Alla fine, la nostra applicazione è piuttosto ingombrante perché modificare gli oggetti nel back-end implica modifiche nel front-end. Inoltre, eseguiamo la convalida sia nel front-end che nel back-end, e questo codice non è condiviso, quindi deve rimanere in fase e mantenuto in due punti.
Le nostre applicazioni sono divise in modo simile a due applicazioni Grails completamente distinte che non condividono alcun codice. Una soluzione che funzionerebbe nel tuo caso ma non è quello che stai cercando, di sicuro.
Nel tuo caso, vedo due soluzioni valide per il web front-end:
utilizzano la Groovy REST client library per andare a prendere e mandare indietro gli oggetti del dominio direttamente dal controller. Se necessario, comprimili in oggetti di comando che riflettono gli oggetti del dominio, in modo da poter condividere il codice di convalida con il back-end.
creare una specie di REST GORM che sostituisce Hibernate con query al servizio Web REST. Si può guardare allo GORM for Mongo Plugin come esempio di come creare tale sostituzione GORM.
Mi piace l'ultima idea, sarebbe un utile plug-in pubblico. Non esiste ancora, sfortunatamente.
hai risposto a molte delle tue domande già nell'affermazione che devi prendere in considerazione servizi Web e un livello di presentazione :) Stai cercando una guida più sull'architettura o sulle scelte tecnologiche?Immagino che la presentazione verrà distribuita su una DMZ e separata dal livello dei servizi da un firewall .. hai altri vincoli architettonici che potrebbero influenzare materialmente una risposta? – darrend
Sto cercando una soluzione Grails-centrica. Mi sembra che la semantica esistano già per la piattaforma per aiutarmi. Considera due estremi: (1) fai notare un plug-in "magic bullet" che trasforma istantaneamente il mio controller, taglib e codice di servizio in modo da renderlo remoto e produce un build di servizi Web per le mie classi di dominio, o (2) tu spiega che Grails è completamente inadatto a separare la presentazione e la persistenza in questo modo. Né è ragionevole, certo, ma nel mezzo, potresti suggerire un modo per sfruttare ciò che ho in un modo che si adatta perfettamente al paradigma di Grails. –
Qual è il motivo dietro al firewall del database, ma consente di eseguire operazioni tramite un servizio Web? Ti aspetti una maggiore sicurezza? Non vedo come possa migliorare la sicurezza. – Antoine