Grails vs Roo - perché SpringSource sta spingendo due tecnologie molto simili?

Question

SpringSource (ora VMWare) ha due tecnologie molto simili: Grails e Spring Roo. Ho usato Grails, ma vedo che SpringSource sta lavorando attivamente su qualcosa che è un concorrente per quella tecnologia e che mi preoccupa per il futuro di Grails.

Qualcuno sa come si collegano queste tecnologie, verranno unite o una di esse verrà abbandonata?

Inoltre, ci sono differenze tecniche importanti tra Grails e Roo?

Answer 1

SpringSource L'obiettivo è quello di rendere il più veloce e semplice possibile per le persone creare, gestire e gestire soluzioni basate su Spring. Abbiamo sia Grails e Spring Roo perché ci preoccupiamo profondamente della produttività degli sviluppatori e, senza dubbio, entrambi questi strumenti offrono un notevole impulso a ciò che i team possono ottenere in primavera.

Abbiamo entrambe le tecnologie perché Roo e Grails sono molto diversi a livello filosofico e di implementazione (come già notato nelle altre risposte). Ogni tecnologia si avvicina al suo linguaggio primario (Java o Groovy) e al modello operativo (dev-time o runtime) con la filosofia di "come rendere la proposizione di valore incredibilmente buona usando questo linguaggio e combinazione di modelli operativi?". Come tale, vedrai ogni tecnologia che adotta uno stile diverso che massimizza quella combinazione (Roo's Java + Dev-time o Grail's Groovy + Runtime) ei benefici commisurati.

Queste differenze sono in realtà molto positive, perché indicano che la comunità Spring può scegliere quale "sapore" di soluzione di produttività preferiscono. Mentre queste differenze iniziali sulla scelta della lingua e sul funzionamento runtime/dev-time sono immediatamente evidenti, la scelta di Grails o Roo si estende anche a considerazioni più sottili come le tecnologie predefinite utilizzate, il modello di interazione dell'utente, il supporto IDE, le dipendenze, gli standard, la roadmap, estensioni ecc. Quasi tutte queste differenze sono una conseguenza naturale del perseguimento di una soluzione best-of-breed per uno stile linguistico particolare.

Il nostro miglior consiglio è considerare entrambe le soluzioni. Ognuno ha i suoi punti dolci, ma ci sono differenze tra i due che renderanno la tua esperienza complessiva migliore con una tecnologia o l'altra in un determinato contesto. Entrambe le guide di riferimento dettagliano lo respective benefits di each solution. Certo, ricorda il tempo che l'investimento è minimo nel provare entrambi. In 10 minuti puoi costruire un progetto in Roo o Grails, quindi prova a vedere cosa ti sembra più naturale per te dato il tuo background specifico e le esigenze del progetto.

Answer 2

La differenza principale è che Roo è un framework Java puro mentre Grails sfrutta Groovy e Java. Entrambi sono basati sulle librerie di base di Spring e si avvalgono delle diffuse librerie open source di Java.

Questa domanda è stata richiamata quando Roo è stato annunciato e Graeme Rocher (responsabile Grails) afferma che entrambi i quadri hanno un posto all'interno di Spring e sono supportati allo stesso modo.

Se non altro, penso che Grails abbia un futuro migliore di Roo. Mi piace sviluppare con esso e non vedo alcun svantaggio che non sia puro Java.

Answer 3

IMO i due non sono molto simili. Anche se ci sono somiglianze il seguenti sono differenze significative:

• Roo utilizza "della-standard Java", Grails è basata su Groovy
• Grails è un framework Web, Roo non è

Roo è molto simile al sistema a riga di comando di Grails (ad esempio il create-app, create-domain-class, test-app, i comandi di tipo trovati in Grails). Non sarei sorpreso di vedere qualche "impollinazione incrociata" tra questa parte del framework Grails e Roo.

Answer 4

Ben Alex di SpringSource parla di Roo in this interview e gli viene chiesto di Grails vs Roo. La differenza principale oltre all'utilizzo di linguaggi diversi (Groovy vs Java come altri menzionati) è che Roo è principalmente uno strumento per lo sviluppo e Grails è più coinvolto nel runtime.

Answer 5

In realtà non sono così simili. Roo è magico in fase di compilazione, in cui Grails è in esecuzione. A causa di questo, i progetti Roo non subiscono alcun impatto sulle prestazioni in fase di esecuzione.

Non riesco a vedere come potrebbero essere uniti poiché Grails è basato su Groovy e Roo su Java.

Answer 6

Grails e Roo sono molto diversi. La prima grande differenza è la lingua utilizzata. Mentre puoi scrivere il codice Groovy come il tradizionale codice Java hai ancora bisogno delle dipendenze di Groovy per eseguire le applicazioni Grails. Per essere il più produttivo possibile in Grails, è necessario avere una conoscenza delle funzionalità di Groovy che attualmente non fanno parte di Java come Closures. Un'altra differenza è la filosofia che le strutture prendono per generare codice. Grails genera molti metodi in fase di esecuzione mentre Roo li genera su richiesta durante il processo di sviluppo. Roo non ha alcuna magia dietro le quinte per l'uso della programmazione orientata all'aspetto, e puoi visualizzare tutto il codice generato da Roo. Ad esempio in Roo è necessario utilizzare un comando per fare in modo che generi metodi di ricerca dinamica come findByBook() e quindi visualizzare il codice generato nei file .aj. In Grails il metodo findByBook() viene creato in fase di esecuzione e non è possibile visualizzare il codice generato. Roo ti permette anche di smettere di usare il framework se scegli di continuare ad avere un'applicazione in esecuzione unendo tutto il codice generato in normali file .java.Quindi non si ha alcuna dipendenza da alcuna libreria Roo in fase di runtime o di progettazione. Se decidi che non ti piace Grails non c'è modo di smettere di usare il framework continuando ad avere un'applicazione funzionante.

Answer 7

Ho visto alcuni commenti sulle mailing list Grail che indicavano che gli autori credevano che Roo esistesse solo come un trampolino di lancio per Grails! Comunque sto valutando personalmente un possibile passaggio da Grails a Roo. Penso che la differenza principale sia tra le lingue dinamiche e quelle tipizzate staticamente: per me è enorme. Adoro molte funzionalità di Grails ma preferisco il supporto IDE e il controllo in fase di compilazione di un linguaggio tipizzato staticamente. Alcuni altri provano esattamente il contrario, quindi cavalli per i corsi. Detto questo, il groovy statico è attualmente in fase di forte sviluppo, quindi chi sa cosa riserva il futuro.

Answer 8

Avevamo un requisito in cui avevamo un'applicazione in produzione ed è stato sviluppato in Spring MVC e la velocità di sviluppo di nuove funzionalità era lenta. Dovevamo esplorare quadri alternativi come Grails e Roo. Ho passato personalmente un mese a esplorare quale fosse meglio.

Se si desidera visualizzare i dettagli della visita di analisi @http://krishnasblog.com/2012/05/08/roo-vs-grails/

Abbiamo esplorato le seguenti caratteristiche sia in questi e in basso è i nostri risultati. Il verdetto finale non è sicuro che ne useremo uno, stiamo ancora esplorando