Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

« Capsules vidéos sur les essais unitaires | Page d'accueil | Capsules sur les essais unitaires »

04 septembre 2012

Roo ou Grails, Roo et Grails

2012-08-31 La semaine dernière, je me suis lancé dans l'exploration de SpringSource Roo afin de le comparer à Grails, aussi de SpringSource, afin de mieux pouvoir conseiller notre organisation.

Divulgation d'intérêt : j'utilise Grails depuis plus de trois ans et mon exploration de Roo se limite à seulement quelques jours. J'ai une préoccupation constante pour livrer des solutions et optimiser la productivité de l'ensemble des équipes impliquées tout au long du cycle de vie de l'application. J'ai fait la promotion de Grails au sein de l'entreprise avec un résultat d'adoption quasi nul (on va voir pourquoi).

Contexte. Depuis deux ans nous utilisons le framework Spring/Hibernate dans nos développements Java avec un certain succès et nous avons débuté l'adoption du TDD. Comme la plupart des développeurs Java, nous constatons que la productivité par rapport à d'autres technologies, notamment .NET, pourrait bénéficier d'un coup de pouce. Attention, la productivité est influencée par de nombreux facteurs. L'objectif ici, est de voir comment nos développeurs, notamment nos développeurs Java, peuvent devenir plus productif. Implicitement, la solution doit rouler dans un environnement Java. Actuellement, nous considérons deux voies : Roo et Grails.

Similarités

Principes. Après exploration, je constate que Roo et Grails partagent plusieurs similarités. Les deux visent l'augmentation de la productivité des développeurs Java, autour de Spring et Hibernate. Les deux sont bien intégrés dans Eclipse (Spring Tool Suite). Il faut souligner l'excellent shell de Roo qui facilite l'utilisation des commandes et qui est supérieur à celui de Grails (un avantage pour l'apprentissage). Grails et Roo misent aussi sur le même concept de "convention over configuration" introduit par Ruby on Rails et qui permet de réduire le travail.

Approche technique. Roo génère du code java (donc, compile time) alors que Grails injecte du code Groovy au run time. Dans ce contexte, Roo à l'avantage de donner au développeur du code statique qu'il peut examiner et compiler. Dans le cas de Grails, comme la magie se passe au run time, il faut plus faire confiance au code. Le code générique qui est injecté par Grails peut aussi être consulté (dans les sources de Grails) mais j'en au rarement vu l'intérêt. Du point de vue du développeur, Grails apparaît plus "magique", mais il faut le voir plutôt comme un niveau plus élevé d'abstraction.

L'approche de Roo génère un war plus petit et requiert moins de dépendances que Grails. Il procure aussi un avantage du côté des performances, bien que pour des applications de gestion normales, je ne pense pas que ce soit un avantage significatif. Si la performance est un enjeu, les deux approches devront faire l'objet d'une attention particulière de toute façon.

Il est important de mentionner qu’autant Grails que Roo capitalisent sur Spring et Hibernate.

Architecture logicielle. J'ai été agréablement surpris de constater que Roo misait sur la même base que Grails. Les "entity" Roo sont presque identiques aux objets "domain" de Grails. Les annotations de Roo pour les "fields" correspondent directement aux "constraints" de Grails. Il en va de même pour le traitement des relations entre les entités où on a simplement à déclarer un "field" du type d'une entité pour établir la relation, comme dans Grails. Même support pour les relations n:m. Comme Grails, Roo génère le squelette des tests unitaires. Les deux génèrent les contrôleurs et les vues. On retrouve dans Roo l'utilisation du "scaffolding", comme dans Grails.

Note: L'apprentissage de Roo se limite essentiellement à quelques concepts dans la façon de réaliser une application Spring/Hibernate. Grails requiert l'apprentissage de ces mêmes concepts, mais aussi une variante du langage Java (Groovy) et de nombreux plugins (ce qui explique le niveau d'adoption).

Donc, comme j'aime Grails et que Roo va dans la même direction, j'aime Roo. Au point où, si je ne pouvais utiliser Grails et que je devais réaliser une application Java, ce serait mon approche de développement privilégiée.

Expérience "out of the box".Construire une application hypersimple, pour une démonstration par exemple, montre que Grails requiert moins de travail et de lignes de code que Roo. L'application Grails est aussi plus riche fonctionnellement que celle produite par Roo. Par exemple, les listes peuvent être triées dans les écrans Grails, mais pas dans ceux de Roo. Le cycle de modification-compilation-exécution est aussi plus rapide dans Grails.

Le nombre de commandes Roo, et donc, dans l'excellent Roo shell est plus limité que celui de Grails.

Plugins. Là où la différence se fait sentir, c'est sur le nombre de "plugins". Actuellement, pour Roo, il n'y en a que quatre (4). Pour Grails, ce nombre est de 830… c'est 200 fois plus!

Cette différence fait que Grails apporte l'intégration de beaucoup de fonctionnalités à peu de frais. Ces plugins, de qualité inégale, il faut le dire, apportent autant des fonctionnalités à l'application qu'au développeur (par exemple pour faire du BDD Behavior Driven Development).

Maturité et apprentissage. Le nombre de commandes, l'envergure des fonctionnalités out-of-the-box et le nombre de plugins découlent directement de la maturité de Grails par rapport à Roo. Grails existe depuis plus longtemps que Roo et est inspiré (et similaire) à Ruby on Rails, lui-même encore plus mature. Il va sans dire que le nombre de ressources (articles, livres, revues, conférences, sites web, communautés…) est largement plus grand autour de Grails que de Roo. Cependant, Roo n'est pas un framework au même titre que Grails. Il faut le voir comme une couche structurante au dessus de Spring/Hibernate. Une couche nécessairement plus mince. Ceci permet de profiter du grand nombre de développeurs Java disponible sur le marché, qui connaissent déjà Spring et Hibernate.

Comparatif

Productivité à maturité :           Grails             >>>            Roo            >             dév. "à la main"

Courbe d'apprentissage :         Grails             >>>            Roo            >             dév. "à la main"

Conclusion. Plusieurs articles sur internet spéculent sur le fait que SpringSource aurait introduit Roo comme "stepping stone", comme une étape intermédiaire, vers l'adoption de Grails. Mon exploration me pousse dans la même direction. Roo est une excellente façon de migrer vers plus de productivité pour un développeur Java d'expérience puisque Roo mécanise une partie de son travail et introduit une architecture logicielle plus moderne.

En se sens Roo me semble une avenue d'amélioration importante pour les équipes Java (spring/hibernate) mature. Grails offre pour le moment, une bien plus grande productivité, mais aux coûts d'un apprentissage beaucoup plus important. Grails représente une cible long terme pour les équipes matures et une cible court terme pour des personnes ayant moins d'expérience en développement et donc moins d'acquis, dans la mesure où on supporte ces développeurs adéquatement.

Donc , selon moi , il ne faut pas parler de Grails ou Roo, mais de Grails et Roo.

 

08:21 Publié dans Grails | Lien permanent | Commentaires (1)

Commentaires

Je cherchais des réponses à mes questions et votre produit correspond exactement à mes recherches

Écrit par : le mal de dos | 04 avril 2014