Grails vs Roo – pourquoi SpringSource pousse deux technologies très similaires?

L’objective de SpringSource est de permettre aux utilisateurs de créer, exécuter et gérer des solutions basées sur Spring aussi rapidement et facilement que possible. Nous avons à la fois Grails et Spring Roo, car nous attachons une grande importance à la productivité des développeurs et, sans aucun doute, ces deux outils apportent un sérieux coup de pouce à ce que les équipes peuvent réaliser en plus de Spring.

Nous avons les deux technologies car Roo et Grails sont très différents au niveau philosophique et au niveau de la mise en œuvre (comme cela a déjà été noté dans les autres réponses). Chaque technologie se rapproche de sa langue principale (Java ou Groovy) et de son modèle d’exploitation (dev-time ou runtime) avec la philosophie de «comment rendre la proposition de valeur incroyablement bonne en utilisant ce langage et cette combinaison de modèles opérationnels? En tant que tel, vous verrez que chaque technologie adopte un style différent qui maximise cette combinaison (Java + Dev-time de Roo ou Groovy + Runtime de Grail) et les avantages correspondants.

Ces différences sont en réalité très positives, car elles signifient que la communauté Spring peut choisir la “saveur” de la solution de productivité qu’elle préfère. Bien que ces différences initiales autour du choix de la langue et de l’exécution / du temps soient évidentes, le choix de Grails ou de Roo s’étend également à des considérations plus subtiles telles que les technologies par défaut, le modèle d’interaction utilisateur, les dépendances, les normes, la feuille de route. extensions etc. Presque toutes ces différences sont une conséquence naturelle de la recherche d’une solution de premier ordre pour un style de langue particulier.

Notre meilleur conseil est de considérer les deux solutions. Chacun a ses points forts, mais il existe des différences entre les deux qui rendront votre expérience globale meilleure avec une technologie ou l’autre dans un contexte donné. Les deux guides de référence détaillent les avantages respectifs de chaque solution . Bien sûr, rappelez-vous que le temps d’investissement est minime pour essayer les deux. En 10 minutes, vous pouvez construire un projet dans Roo ou Grails, alors essayez-le et voyez ce qui vous semble le plus naturel compte tenu de vos antécédents et de vos besoins spécifiques.

La principale différence est que Roo est un framework Java pur alors que Grails utilise Groovy aussi bien que Java. Les deux sont construits sur les bibliothèques de base de Spring et utilisent des bibliothèques Java open source populaires.

Cette question a été posée lors de l’annonce de Roo et Graeme Rocher (responsable de Grails) affirme que les deux frameworks ont une place dans Spring et sont supportés de manière égale.

En tout cas, je pense que Grails a un avenir meilleur que Roo. J’adore développer avec et ne pas voir les inconvénients à ne pas être pur Java.

Grails et Roo sont très différents. La première différence majeure est la langue utilisée. Bien que vous puissiez écrire du code Groovy comme le code Java traditionnel, vous avez toujours besoin des dépendances Groovy pour exécuter les applications Grails. Pour être aussi productif que possible dans Grails, vous devez également connaître les fonctionnalités de Groovy qui ne font pas actuellement partie de Java, telles que les fermetures. Une autre différence réside dans la philosophie adoptée par les frameworks pour générer du code. Grails génère beaucoup de méthodes à l’exécution, tandis que Roo les génère à la demande pendant le processus de développement. Roo n’a pas de magie dans les coulisses pour l’utilisation de la programmation orientée aspect, et vous pouvez voir tout le code généré par Roo. Par exemple, dans Roo, vous devez utiliser une commande pour générer des méthodes de recherche dynamics telles que findByBook (), puis afficher le code généré dans les fichiers .aj. Dans Grails, la méthode findByBook () est créée à l’exécution et vous ne pouvez pas afficher le code généré. Roo vous permet également d’arrêter d’utiliser le framework si vous le souhaitez tout en continuant à avoir une application en cours d’exécution en fusionnant tout le code généré dans des fichiers .java normaux. Vous n’avez alors aucune dépendance sur les bibliothèques Roo à l’exécution ou à la conception. Si vous décidez que vous n’aimez pas Grails, il n’y a aucun moyen d’arrêter d’utiliser le framework tout en continuant à avoir une application qui fonctionne.

IMO les deux ne sont pas très similaires. Même s’il existe des similitudes, les différences suivantes sont significatives:

• Roo utilise “Java standard”, Grails est basé sur Groovy
• Grails est un framework Web, Roo n’est pas

Roo est très similaire au système de ligne de commande de Grails (par exemple, les commandes create-app , create-domain-class , type de test-app trouvées dans Grails). Je ne serais pas surpris de voir une “pollinisation croisée” entre cette partie du cadre Grails et Roo.

Ben Alex de SpringSource parle de Roo dans cette interview et il est interrogé sur Grails vs Roo. La principale différence en dehors de l’utilisation de langages différents (Groovy vs Java comme d’autres l’ont mentionné) est que Roo est principalement un outil de développement et que Grails est plus impliqué dans l’exécution.

Ils ne sont pas vraiment similaires. Roo fait de la magie au moment de la compilation, là où Grails le fait fonctionner. À cause de cela, les projets Roo ne subissent aucune perte de performance à l’exécution.

Je ne vois pas comment ils pourraient être fusionnés car Grails est construit sur Groovy et Roo sur Java.

J’ai vu quelques commentaires sur les listes de diffusion de Grails qui indiquaient que les auteurs pensaient que Roo n’existe que comme tremplin pour Grails! Cependant, je considère personnellement un possible passage de Grails à Roo. Je pense que la principale différence est entre les langages dynamics et les langages typescripts – pour moi, c’est énorme. J’aime beaucoup de fonctionnalités de Grails mais je préfère la prise en charge IDE et la vérification à la compilation d’un langage typé statiquement. Certains ressentent exactement le contraire, donc des chevaux pour les cours. Cela dit, le groovy statique est actuellement en plein développement, alors qui sait ce que réserve l’avenir.

Nous avions une exigence en matière de production et nous avons développé Spring MVC et la vitesse de développement de nouvelles fonctionnalités était lente. Nous avons dû explorer des frameworks alternatifs tels que Grails et Roo. J’ai personnellement passé près d’un mois à explorer celle qui était la meilleure.

Si vous voulez voir les détails de l’parsing, visitez @ http://krishnasblog.com/2012/05/08/roo-vs-grails/

Nous avons exploré les caractéristiques suivantes dans ces deux domaines et ci-dessous sont nos résultats. Le verdict final nous ne sums pas sûr que nous utiliserons l’un ou l’autre, nous explorons toujours