Face à la montée en puissance des nouveaux frameworks web comme RubyOnRails, Django ou Symfony, Grails propose une solution comparable pour le monde Java. Quels sont ses principales caractéristiques ? Va-t-il devenir incontournable pour les développements web Java ?
Groovy et Grails
Groovy est un langage de script basé sur Java. Il est standardisé par la [JSR-241->http://jcp.org/en/jsr/detail?id=241]. C’est un langage objet, au typage dynamique qui peut s’interfacer avec des classes Java traditionnelles. En effet, le code écrit en Groovy est compilé sous forme de bytecode Java. Sa syntaxe reprend dans les grandes lignes celle de Java en y ajoutant des facilités d’écriture de certaines structures, permettant ainsi de faire de Groovy un langage moins verbeux.
Grails est un framework RAD utilisant Groovy comme langage. Il inclut les différentes couches que l’on peut attendre d’un RAD : ORM, MVC, Service. L’objectif de Grails est de fournir une structure définie et des outils simples, ce qui permet une productivité de développement importante.
Convention over Configuration
La philosophie principale de Grails est Convention over Configuration (les conventions plutôt que la configuration) afin de permettre une grande rapidité de développement et de s’affranchir des tâches les plus rébarbatives pour se concentrer essentiellement sur la logique métier.
Arborescence du projet
Voici quelques exemples illustrant ce principe. Tout d’abord, l’arborescence du projet en elle-même utilise les conventions :
+ grails-app
+ conf
+ controllers
- BookController.groovy
+ domain
- Book.groovy
...
+ views
+ book
- list.gsp
- view.gsp
+ layouts
- main.gsp
Pour définir une classe du modèle, il suffit de la créer dans le répertoire domain. Elle sera automatiquement reconnue. De la même manière, une classe a juste à être créée dans le répertoire controllers pour être considérée comme un contrôleur. Ces méthodes seront automatiquement mappées à des actions. Il suffit également de nommer les vues en utilisant le nom de l’action pour qu’elles soient automatiquement utilisées.
Mapping Objet/Relationnel
Le mapping Objet/Relationnel se fait de la même manière. Les noms et les types des propriétés des classes du modèle sont utilisés pour générer les colonnes en base de données. Ce fonctionnement répond à la majorité des besoins, et Grails permet de surcharger ce comportement par défaut de manière très simple, ce qui permet de ne pas se retrouver bloqué par le framework.
Exemple de classe du modèle :
class Book String Title
String Author
String description
static constraints = {
description(maxSize:1000) // Fixe la taille maximale pour la colonne description
}
Injection de dépendance
L’injection de dépendance se fait également de manière automatique. Par exemple, pour utiliser un service depuis un contrôleur, il suffit de nommer une variable en reprenant le nom de la classe du service pour qu’il soit automatiquement injecté :
CountryService.groovy
class CountryService def getName(id) {
...
}CountryController.groovy
class CountryController def countryService
def show = {
name = countryService.getName( params.id )
...
}
Ici aussi, ce comportement par défaut peut être modifié dans le cas de besoins plus spécifiques.
MVC
La couche MVC est basée sur Spring MVC et en reprend les fonctionnalités. Elle inclut également une gestion des « flows » basée sur Spring WebFlow. Mis à part le principe de « convention over configuration » Grails n’apporte pas de fonctionnalités supplémentaires.
Plugins
En plus des fonctionnalités offertes par défaut dans le framework, un système de plugins permet de l’étendre facilement. La ligne de commande permet de les ajouter très facilement.
De manière générale, la configuration des plugins se fait dans le fichier de configuration de l’application quand elle est simple et dans un fichier dédié lorsqu’elle est plus complexe. Ce principe de fonctionnement rejoint la philosophie générale de Grails : simplifier aux maximum les cas simples tout en permettant de gérer proprement les cas plus complexes.
Voici quelques exemple de plugins existants intéressant :
– Webservices
– AcegiSecurity
– Indexation
– GWT
Intégration avec Java
Une des forces de Groovy et Grails concerne l’accès à des classes écrites en Java et inversement, des classes Java peuvent utiliser des classes Groovy. Ce point offre un net avantage à Grails par rapport aux autre frameworks web dans les contextes où Java est déjà présent. Il est possible de déployer une application Grails sur n’importe quel serveur d’application Java. La ligne de commande permet de générer le fichier war à déployer.
Groovy n’apporte que très peu d’API supplémentaires à celle de Java, c’est pourquoi il est facile à prendre en main par un développeur Java et il donne accès à la richesse de fonctionnalités de l’API et des librairies annexes.
Grails utilise en interne des frameworks JEE très populaires : Spring, Hibernate. Ceci offre l’avantage de pouvoir pousser très loin l’intégration avec des sytèmes existants. Par exemple, on peut très facilement utiliser des classes du modèle déjà créées et configurées avec Hibernate, ou bien injecter un service déjà existant développé en Java à l’aide de Spring.
On pourrait même imaginer n’utiliser Grails que pour la partie MVC et conserver le modèle et les services en Java.
Le framework RAD JEE d’avenir ?
Grails a beaucoup d’arguments en faveur de son adoption, une rapidité de développement comparable à RoR, Django ou Symfony, la possibilité d’intégration à un existant Java, la robustesse de la plateforme d’exécution. Cependant, il faut un peu tempérer ces points.
Tout d’abord, Grails est basé sur Groovy qui, même si il ressemble à Java, est un langage nouveau qu’il faut prendre en main. Les compétences actuelles sur le marché sont très limitées. De plus, les outils de développement ne sont pas encore aussi avancés que pour Java.
Mais surtout, il est important de noter que les frameworks Java traditionnels évoluent. En effet, une prise de conscience de la nécessité de simplifier les développements a eu lieu, et les nouvelles versions de ces frameworks vont dans ce sens. Même si ils n’offrent pas encore une simplification aussi poussée que Grails, voici quelques exemples qui montrent que c’est la direction actuellement suivie :
– Hibernate 3 a apporté une simplicité de configuration. Le mapping Objet/Relationnel ne nécessite plus de fichier de configuration XML interminable, notamment grâce aux annotations.
– Spring IoC propose une injection de dépendances soit par annotations, soit similaire à Grails grâce à l’autowiring
– Spring MVC utilise le concept de Convention over Configuration pour gérer le mapping URL/Contrôleur.
– Struts 2 permet d’utiliser maintenant directement les classes du modèle pour gérer les formulaires (voir ici) et on peut également créer des actions sans les déclarer dans un fichier XML, uniquement par convention de nommage .
Conclusion
Grails offre une rapidité de développement qui s’inscrit tout-à-fait dans les méthodes de développement actuelles. Le fait qu’il soit totalement intégrable à un existant Java et qu’il repose sur des briques robustes et éprouvées (JEE, Hibernate, Spring) sont des arguments solides en faveur de son adoption.
Toutefois, les compétences (développement, expertise …) sur le marché sont peu répandues et les retours d’expérience manquent encore pour limiter les risques sur des projets de taille importante. D’autant que dans le même temps, les frameworks JEE traditionnels progressent en terme de simplicité et de productivité tout en possédant des fonctionnalités très avancées, une robustesse éprouvée, tout en présentant l’avantage de disposer de ressources compétentes plus facilement.
Pour bénéficier à plein de Grails, nous recommandons de le mettre en œuvre sur un nouveau projet de taille moyenne. Dans ce cas, le gain sera particulièrement intéressant, notamment au niveau du démarrage du projet. Le temps de prise en main, assez court pour des développeurs Java, n’est pas un frein à son adoption. Enfin, l’utilisation de Grails peut être une bonne occasion de mettre en pratique les principes des développements agiles (moins de spécifications, rapprochement des fonctionnels et des développeurs, …) et de tester leur adéquation à votre contexte.
