2010-05-29 12 views
5

Ho guardato framework web come Rails, Grails, ecc. Sono abituato a fare applicazioni in Spring Framework con Hibernate ... e voglio qualcosa di più produttivo.Quale piattaforma web è adatta a me?

Una delle cose che ho capito è che mentre alcune delle cose in Grails sono sexy, ci sono alcuni problemi seri con esso. I controller di Grails:

1) sono implementati in modo anomalo. Non sembrano in grado di estendersi dalle super classi in fase di runtime. Ho provato questo per aggiungere azioni di base e metodi di supporto, e questo sembra far esplodere i graal.

2) si basano su un modello di parametri di richiesta obsoleto (anziché su oggetti di backing, che sono molto più belli).

3) sono difficili da testare. Gli oggetti di comando sono trattati in modo completamente diverso ... ed è MOLTO più difficile scrivere il test piuttosto che scrivere il codice del controller.

4) Gli oggetti di comando funzionano in modo completamente diverso. Sono pre-validati e rilegati, il che causa molte incoerenze rispetto al modello di parametri di base.

5) Gli oggetti di comando non sono riutilizzabili, ed è un problema nel retro riutilizzare la maggior parte delle cose dalle classi di dominio, come vincoli e campi. Questo è TRIVIAL da fare in primavera base. Perché diavolo non era banale da fare a Grails?

6) Il ponteggio generato è pura merda. Non generalizza inserti e aggiornamenti ... e in realtà copia/incolla una pila di codice in due viste: create.gsp e edit.gsp. I panorami sono enormi mucchi di dozzine di cagnolini. Ciò è ulteriormente aggravato dal fatto che utilizza parametri di basso livello e non oggetti.

I test di integrazione sono 30 volte più lenti di un test di integrazione Spring. È disgustoso.

Alcuni test di simulazione sono così difficili da scrivere e non è garantito che funzionino quando vengono distribuiti, il che ritengo scoraggino i cicli di test veloci, tdd.

La maggior parte delle cose sembra rovinare i grails mentre è in esecuzione, come aggiungere un taglib o qualcosa di veramente. Il problema di riavvio del server non è stato risolto affatto.

Sto iniziando a pensare che andare con Spring/Hibernate/Java sia l'unica strada da percorrere. Mentre c'è un costo piuttosto grande all'avvio, so che alla fine si appianerà.

Fa schifo Non posso usare un linguaggio come Scala ... perché in modo idiomatico, è così incompatibile con Hibernate.

Questa app non è nemmeno un'interfaccia utente ordinata su un database. Ne ha un po ', ma non sarà un po' molle. Ho paura mortale di Grails ora a causa di come è schifoso nel livello Controller.

Suggerimenti su cosa posso fare?

+0

"Fa schifo Non posso usare un linguaggio come Scala ... perché in modo idiomatico, è così incompatibile con Hibernate." - interessante, vorresti approfondire? –

+0

Fondamentalmente, poiché molti dei metodi Spring/Hibernate prendono o restituiscono un oggetto, devi fare un sacco di asInstanceOf [Bleh] nel tuo codice. C'è anche una mancata corrispondenza tra scala collezioni e collezioni java, quindi è necessario aggiungere un po 'di abbondanza per convertirli. C'è anche una performance. Quando si usano le annotazioni, scala ha bisogno di usare Array (...) attorno ad ogni parametro perché non ha un'eccezione di un elemento costruita nel systax ... il che rende alcune cose un po 'più gonfie. – egervari

+0

perché usare un'istanza di? Perché non aggiungere informazioni sul tipo di oggetto? –

risposta

3

All abstractions leak. Hai nominato sei oggetti sul lato opposto per i graal. Uno per la primavera. A quanto pare, preferiresti Spring, allora.

4

Si potrebbe verificare il Play! framework. Attualmente sto lavorando a un'applicazione in Grails che sembra andare bene e non ha davvero funzionato molto con il framework di gioco, quindi potrebbe funzionare o meno per te. Una delle aggiunte recenti al framework di gioco è il modulo Scala che consente di codificare in Scala.

1

Sto iniziando a pensare di andare con Spring/Hibernate/Java è l'unica strada da percorrere. Mentre c'è un costo piuttosto grande all'avvio, so che alla fine si appianerà.

Poi magari uno sguardo al Spring Roo (anche leggere Grails vs Roo - why SpringSource is pushing two very similar technologies?).

+1

Sì, ma anche nelle dimostrazioni le cose sono andate male ... quindi non so. Odio anche eclissi e so che non ho bisogno di usare eclipse, ma l'ultima volta che ho provato a far funzionare Roo con IDEA, era un no-go. Neanche a me piacciono i jsp crudi. Sto intrattenendo l'idea di fare il progetto in scala al momento. – egervari

1

Ho utilizzato Grails in un paio di progetti nel corso dell'ultimo anno e ho scoperto che la produttività di sviluppo guadagna di gran lunga superiore agli svantaggi e non ho trovato un problema che non avrei potuto aggirare.

Per quanto riguarda alcune delle vostre specifiche obiezioni:

1) sono implementate terribilmente. Non lo sono sembrano essere in grado di estendersi dalle classi super in fase di esecuzione. Ho provato questo a aggiungere azioni di base e metodi di supporto, e questo sembra causare graal per soffiare su.

FWIW, Non ho mai sentito la necessità di estendere il controller da una classe base. Ogni controller supporta specifiche chiamate HTTP che non si prestano al riutilizzo, e qualsiasi cosa necessaria al riutilizzo può/deve essere delegata a un servizio.

2) sono basati su un modulo parametri modello obsoleto (anziché forma oggetti chitarra, che sono molto più).

Ancora una volta, FWIW questo non è stato un problema per me. Grails racchiude tutti i parametri in una mappa, che è tutto ciò di cui ho bisogno. Se ho bisogno di più, creo un oggetto Command, che è piuttosto semplice.

3) sono difficili da testare. Gli oggetti di comando sono trattati in modo completamente diverso ... e in realtà è MOLTO più difficile scrivere il test piuttosto che scrivere il codice del controller .

Yep-testing in grails è uno dei suoi punti bassi. Ho abbandonato completamente le imbracature di prova di Grails e uso semplicemente Selenium per automatizzare i test tramite la GUI. Non ideale, ma ha funzionato bene per noi.

6) Il ponteggio generato è puro schifo. Non generalizza gli inserimenti e gli aggiornamenti ... e in realtà copia/incolla una pila di codice in due viste : create.gsp e edit.gsp. Le visualizzazioni sono mucchi giganteschi di dozzina di cane. Questo è ulteriormente aggravato dal fatto che utilizza i parametri di basso livello e non gli oggetti.

In realtà ho trovato che l'impalcatura è molto utile per iniziare. Non è mai in produzione nella sua forma nativa (tranne occasionalmente per le app interne), ma consente di risparmiare un sacco di tempo per iniziare a sviluppare elementi di base della tua app. Inoltre, puoi sempre creare i tuoi modelli di scaffold se non ti piacciono quelli forniti.

test di integrazione sono 30x più lento di un test di integrazione primavera. È disgustoso.

Alcuni test beffardi sono così difficili da scrittura e non sono garantiti per lavorare quando è schierato, che penso che scoraggia veloci cicli di prova TDD.

Di nuovo, sì, il test non è un abito forte di Grails.

La maggior parte delle cose sembrano rovinare graal mentre è in esecuzione, come l'aggiunta di un taglib , o qualcosa di veramente. Il problema di riavvio del server non è stato risolto affatto.

Non ho avuto alcun problema in questo settore da quando è uscito 1.2. È il più pulito ambiente in cui è stato eseguito il cambiamento durante l'esecuzione. Certamente ci sono alcune cose che richiedono un riavvio (ad esempio mod per il bootstrap), ma per la maggior parte delle fasi di sviluppo funziona benissimo.

sto iniziando a pensare di andare con Primavera/Hibernate/Java è l'unico modo per andare . Sebbene all'avvio ci sia un notevole costo di , so che alla fine si spaccherà lo .

Non solo all'avvio, ma durante tutto il processo di sviluppo. Immagino che i team con cui sto lavorando stiano producendo funzionalità pronte per la produzione con una velocità di 3-5 volte più veloce che potremmo utilizzare con i framework "tradizionali". Non è certo per tutti e per ogni progetto, e non è perfetto, ma può essere un enorme acceleratore se il tuo progetto si adatta ai punti di forza di Grails. Aggiungete a ciò il fatto che potete in gran parte scegliere e decidere quanto Grails volete usare (o toccare i livelli Spring/J2EE se volete), e lo vedo come un'opzione "avere la vostra torta e mangiarlo troppo". Il mio 2c.

Problemi correlati