Groovy / Grails est une bouffée d’air frais pour le programmeur Java, vous permettant d’écrire du code plus expressif et plus lisible, sans les lourdeurs de Java ou de JEE. Groovy vous simplifie également la vie en vous épargnant les écueils classiques du programmeur débutant ou distrait (BigDecimal, equals(), etc…). Ce n’est pas pour autant suffisant pour s’assurer de la qualité du code délivré et il vous faudra là aussi un ensemble de pratiques pour garder un code maintenable malgré les ajouts et évolutions.

Une de ces pratiques est l’analyse statique de votre code source via des métriques et des règles, et la surveillance de leur évolution d’une version sur l’autre, ou de manière plus ciblée pour une version particulière. Dans ce domaine le programmeur Java est sans aucun doute l’un des mieux outillés, avec des outils comme PMD, FindBugs, CheckStyle, XDepend, Sonar etc… Qu’en est-il en Groovy / Grails ?

L’article complet, en anglais uniquement, aborde les points suivants :

• les outils disponibles en Groovy, à savoir GMetrics, CodeNarc, Sonar
• la pertinence des autres outils Java sur du code Groovy, par exemple PMD, FindBugs, CheckStyle ou XDepend
• la spécificité des langages dynamiques et l’importance des tests et d’une métrique comme la couverture de tests
• comment mettre en place la solution retenue sur votre projet Grails : Sonar, plus précisément le plugin Groovy pour Sonar
• une ouverture sur l’impact d’un IDE sur la qualité du code et les possibilités d’analyse d’IntelliJ via les « inspections »

En guise de teaser, voici un exemple de tableau de bord Sonar sur un projet Grails :

Suggestion d'articles :

1. Paris JUG : Groovy et Grails
2. Transactions et traitement métier en Grails
3. Retour sur le JUG de Lausanne sur l’analyse de la qualité du code Java

#Exemple de manipulation de collection avec une closure
print ["google", "yahoo", "bing"].map{|host| "http://www.#{host}.com" }
> ["http://www.google.com", "http://www.yahoo.com", "http://www.bing.com"]

Ces caractéristiques ont sans aucun doute marqué le monde du développement, mais elles ont désormais été intégrées par de nombreux langages. Ainsi, Spring ou JEE sont profondément emprunts de convention over configuration et de don’t repeat yourself permettant d’alléger les fastidieux fichiers de configuration XML. Les langages JVM de nouvelle génération (dynamiques ou non) comme Groovy ou Scala sont désormais matures. Et pour finir, l’outil JRebel propose une solution efficace au problème de « hot deploy » en Java.  Ces 3 points ne justifient donc pas en eux même de privilégier Rails à une stack Java.

Mais ne nous méprenons pas, la principale force de Rails est d’être un framework web ; en effet, point d’embarqué ou de client lourd en Rails. Mais cette spécialisation, qui correspond malgré tout à 95% de mon utilisation de Java en entreprise, est réellement un atout. En parlant de Java j’ai maintenant l’image d’un tank : ça fait tout, ça finit par passer partout, mais pas forcément de la plus efficace et la plus élégante des manières.

Le reste de cet article sera donc consacré à opposer Rails à Java en tant que frameworks web.

Mais au fait, Java peut il concourir dans la catégorie framework web ? Oui et non : Java n’est pas un framework web en tant que tel et l’on considérera en fait Java comme une pile de frameworks. On peut aussi bien utiliser la pile Java officielle (JEE), une pile alternative (comme Spring ou JBoss Seam) ou encore un assemblage à façon des nombreux frameworks existants.

Et en fin de compte, cette variété de frameworks nuit à Java : elle apporte beaucoup de complexité, aussi bien dans le choix des briques que dans leur assemblage. Ainsi la communauté Java s’est longtemps consacré à simplifier l’intégration entre les frameworks et entre les couches d’une application (l’IOC n’a jamais été aussi simple et peu verbeux). Cet objectif est aujourd’hui atteint et la pile standard Java est enfin devenue aussi légère à utiliser qu’elle devrait l’être.

Mais ceci s’est fait au détriment de ses fonctionnalités ! On s’estime aujourd’hui heureux en Java lorsque le framework que l’on utilise nous permet de mettre en oeuvre simplement le pattern MVC, de binder des objets sur des composants graphiques, de faire de la validation et éventuellement de faire un peu d’Ajax. C’est bien, mais c’est le b.a.-ba du web.

Si j’utilise aujourd’hui Rails, c’est parce que ce framework est définitivement plus abouti et plus riche en terme de fonctionnalités web. Rails (contrairement à Java) est le fruit de centaines de contributeurs oeuvrant tous dans le même sens : faire de ce framework le plus productif pour réaliser des applications web. Voici quelques exemples de fonctionnalités natives en Rails, et à mon sens vitales pour faire une application web en 2010 :

• Mapping REST et contrôle fin des URLS générées
• Exposition de services web en JSON ou XML

#controlleur MVC pour retourner un objet sérialisé en JSON
class BooksController < ApplicationController   def show     render :json => Book.find_by_id(params[:id])
  end
end

• Gestion intégrée d’un memcache ou encore gestion du cache pour des fragments de page
• Compression automatique des ressources web
• Accès transparent à la base de donnée (ie. pas besoin d’écrire de code SQL ou apparenté pour une bête recherche en base)

class User < ActiveRecord::Base
  #la classe est vide, les attributs de la classe sont induits depuis le schema de la base : schema.rb
end
 #exemple de méthode dynamique : Rails interprète dynamiquement le nom de la méthode pour exécuter le code SQL correspondant
User.find_by_name

Il y a aussi une gem pour ça !

Et ce n’est pas parce que Rails bénéficie d’une direction claire et contrôlée qu’il n’existe pas de communauté. La contribution externe est très riche, et les frameworks pululent sur github. Voici quelques exemples de gem (i.e. librairie Ruby) absolument bluffantes :

• devise vous aide à gérer tous les aspects sécurité. Pas seulement le processus d’authentification, mais aussi toute l’ihm nécessaire à enregistrer un nouvel utilisateur, changer son mot de passe ou encore confirmer la création de son compte. Devise est extensible et s’intègre particulièrement bien à openid ou oauth (pour utiliser Facebook ou Twitter en SSO par exemple)
• formtastic simplifie drastiquement l’écriture de vos formulaires en poussant au plus loin le paradigme « convention over configuration ».
• si vous trouvez que le HTML est verbeux, pas vraiment DRY et finalement peu maintenable, la gem HAML est faite pour vous. Elle a pour vocations à faire de vos pages web de véritables Haïku ;-)
• pour finir typus ou admin_data vous aident à générer un back-office d’administration en deux coups de cuillère à pot.

Il y a bien entendu le risque de retomber dans une situation similaire à Java ou l’on se retrouve à assembler des stacks de gems totalement hétérogènes d’un projet à l’autre avec un surcoût d’intégration important. Mais Rails s’en sort mieux sur ce point car d’une part la « colonne vertébrale » d’un projet Rails est standard alors que ce n’est pas le cas en Java (où l’on peut être basiquement en  JEE, Spring ou Seam), et d’autre part les meilleurs innovations sont régulièrement injectées dans le coeur de Rails (tandis que la standardisation d’un Hibernate en JPA reste une situation exceptionnelle)

La communauté Rails est extrêmement importante et les contributions sont variées :

• des foisons de gems et plugins sur github
• d’excellents guides sur les concepts clés de Rails
• quelques blogs majeurs ou encore quelques screencasts
• de nombreux services sur le cloud
• des milliers de questions et réponses sur stackoverflow

Un framework fait par des agilistes, pour des agilistes

Un critère devenu extrêmement important ces dernières années lors de l’évaluation d’un framework est sa testabilité. Qu’en est-il avec Rails ?

Et bien soyez rassurés, il n’y a aucun doute à avoir : Rails est le framework le plus testable que j’ai pu utiliser ces dernières années. La première raison est que par défaut un projet Rails embarque toute la mécanique permettant de mettre en oeuvre 3 stratégies de test différentes, toutes complémentaires, pour tester votre application :

• la plus importante, le test unitaire, peut être utilisée pour tester n’importe quel objet de votre application : principalement les modèles mais aussi n’importe quelle librairie.
• les tests fonctionnels permettent de tester unitairement un controlleur et fournissent le nécessaire pour injecter simplement des requêtes HTTP et vérifier le rendu HTML (ou autre)
• pour finir les tests d’intégrations sont des sortes de super tests fonctionnels, permettant de tester un enchainement de pages et de controlleurs.

#exemple de test d'intégration
class UserFlowsTest < ActionController::IntegrationTest
   fixtures :users
   test "login and browse site" do
     https!
     get "/login"
     assert_response :success
     post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
    assert_equal '/welcome', path
    assert_equal 'Welcome avs!', flash[:notice]

    https!(false)
    get "/posts/all"
    assert_response :success
    assert assigns(:products)
  end
end

Et pas la peine de vous demander comment est géré l’état de la base de donnée pour ces tests : Rails gère pour nous toute cette configuration fastidieuse. Souvenez-vous donc ce que l’on doit faire en Java : configuration d’une base de données mémoire, génération automatique du schéma avec JPA, gestion des jeux de données DBUnit …

La seconde raison est que la communauté Rails propose des outils de tests bluffants (et pour le coup, bien loin de ce qui existe en Java). Les deux que j’ai envie de retenir sont:

• factory_girl, qui permet de définir des modèles d’objet et de les réutiliser facilement dans tous ses tests. Chaque test peut rester « ciblé » sur ce qui doit être testé.
• cucumber, pour sa part est un outil de « spécifications exécutables » sur lequel nous avons déjà rédigé quelques articles. Il s’agit tout simplement de l’outil le plus expressif qui existe pour rédiger des tests (et en français dans le texte !)

Sans aucun doute, Ruby on Rails peut donc être utilisé en contexte agile. Et comme l’agilité ne s’arrête pas aux tests, Rails va plus loin :

• le déploiement automatisé est extrêment aisé avec Capistrano. Et même encore plus simple si vous utilisez un hébergeur comme heroku (git push heroku et ça tourne sur le cloud !)
• la gestion incrémentale des bases de données, longuement décrite dans cet article, existe nativement dans Rails. Et par exemple, si l’un de vos coéquipiers livre du code altérant la base de données il vous suffira de lancer la commande « rake db:migrate » pour appliquer ces modifications (bien entendu pas besoin de redémarrer le serveur, même si c’est un réflexe bien ancré chez les Javaistes ;-) )

Suggestion d'articles :

1. Présentation Rails au Paris JUG

Développer en Groovy et Grails simplifie grandement le développement d’une application Web. Passée l’étape du prototype, les simplifications apportées par Grails ne vous épargneront pas de devoir vous plonger dans les frameworks sous-jacents afin de résoudre des problématiques plus complexes.

Qu’en est-il des transactions en Grails ? Sur un sujet aussi sensible, il est important de comprendre quel est ce comportement par défaut choisi par Grails.

La documentation de Grails est un peu sommaire, ne traitant vraiment que de où et comment les déclarer mais pas vraiment de comment les utiliser. Les premiers points ne seront pas ré-expliqués ici, vous pouvez vous référer à la documentation.

L’article complet, en anglais uniquement, aborde les points suivants :

• le modèle transactionnel de Grails, par défaut dans la couche de Services
• les risques et pièges de ce modèle, à savoir un traitement métier en dehors d’une transaction ou réparti sur plusieurs transactions
• les bonnes pratiques pour gérer et déclarer les transactions en Grails
• les interactions parfois étranges entre les transactions et la session Hibernate
• une alternative au modèle transactionnel de Grails pour simplifier la gestion des transactions et supprimer les risques identifiés auparavant. L’article inclus le code nécessaire à cette modification et explique les impacts d’une telle modification.

Vous pouvez retrouver le code et les tests mentionnés dans cet article dans notre repo SVN .

Suggestion d'articles :

1. GRAILS et FitNesse : au service de l’innovation métier
2. Analyser la qualité de votre code Groovy / Grails
3. GemFire et traitement distribué

Dans un article précédent, Yannick prônait l’innovation durable illustrée dans le secteur des Télécom, auquel un commentateur zélé répondait qu’icelle « n’est pas une question de technologie, ni d’architecture de SI », invoquant même le directeur marketing de Coca-Cola (lire).

Je suis assez tenté de rejoindre votre position, cher commentateur. D’autant plus que, chez OCTO, l’innovation que je vais vous présenter a démarré bien loin de l’IT.

OCTO, nombre de lecteurs l’auront évidemment compris, est fervent partisan de l’intégration des méthodes Lean dans le SI. Le kaizen (amélioration continue), issu des pratiques industrielles de Toyota, reste un maître mot dans l’accompagnement de nos clients.

Pour tordre le cou au droit proverbial des cordonniers à être mal chaussés, j’avais décidé de mettre en place cette pratique en interne. L’innovation proposée devait amener de la valeur à un public ciblé, sans bousculer les habitudes de travail, avec un investissement initial restreint.

Le sujet était tout trouvé : améliorer la communication commerciale essentielle vers les consultant(e)s. En effet, tous étaient et sont toujours susceptibles d’être intéressés par les propositions commerciales en cours, celles (brillamment !) gagnées et celles (étonnamment !) perdues et ce, au fil de l’eau.

Allais-je lancer une expression des besoins puis une recette auprès de key users habilement sélectionnés ? Allais-je me ruer tête baissée vers une extraction journalière des données de notre ERP pour une diffusion par mail aux abonnés ?  Allais-je tout simplement me lancer dans la technologie pour innover ? Le suspense est insoutenable, vous le sentez aussi.

Pour tester et démontrer la valeur de mon innovation, j’ai plutôt choisi de prototyper éco : économique et écologique.

• Un tableau en liège grand format installé dans la cafét’ (en face du baby-foot)

• Des post-it de couleurs variées (les couleurs illustreront les secteurs de nos clients sur lesquels est structurée notre organisation)

• Des punaises de qualité irréprochable

• Et… c’est malheureusement tout : je sais, c’est cruel pour les technophiles technocentriques

Le tableau est divisé en trois sections : en cours, gagnées, perdues. Sur les posts-it, le nom du client et l’intitulé de la mission gribouillés au marqueur. La purge est mensuelle.

Mon objectif : susciter l’adhésion des  gestionnaires commerciaux (écrire un post-it à la pause café ne coûte pas), obtenir un feedback de TOUS les utilisateurs sans les assaillir (pendant qu’on discute autour d’un café, on peut commenter les missions affichées) et initier le changement sans rupture (l’information pertinente est accessible sans efforts).

Le projet a été plébiscité, et depuis plus de six mois désormais, le tableau est régulièrement mis à jour et a subi quelques modifications suggérées par les utilisateurs.

Passer à la technologie était l’étape complémentaire : quelques modifications de code dans notre ERP maison, l’ajout d’un feed RSS sur les missions et le tour était joué. Modifier le code était relativement aisé puisque notre logiciel (basé sur le framework Grails) était balisé par un harnais de tests automatisés (*). Implémenter un flux RSS était redoutablement facile, mais vous devez achever la lecture de ce billet pour comprendre pourquoi : c’est visiblement l’article de tous les suspenses.

Alors, innover sans technologie c’est non seulement possible mais c’est indispensable lorsque le contexte s’y prête :

• Les utilisateurs ne sont pas bousculés, au contraire ils sont tacitement incités à participer à l’élaboration du projet par des suggestions immédiates ou du fait de la facilité à modifier soi-même (changer la disposition ou la couleur des posts-it),
• L’investissement initial est marginal (chez OCTO, on peut encore se servir de posts-it sans remplir cinq formulaires) et autorise l’échec,
• Toutes les castes sont impliquées et valorisées d’emblée : les directeurs, les commerciaux, les consultants, les stagiaires : tous transitent une fois par jour au moins à la salle café (au moins trois fois par jour pour les stagiaires) et constatent l’épanouissement du business de notre société.

La partie technique

Les articles informatiques, c’est comme les bons yaourts aux fruits : c’est toujours meilleur avec des morceaux dedans.

La plateforme Grails qu’on ne présente plus possède un plug-in spécifique : Feeds. Grâce à l’expressivité intrinsèque de Groovy et à l’implémentation masquée des mécaniques de flux (RSS/ATOM), ce plug-in a permis de développer la version technologique du tableau de la salle café en deux heures à peine, tests inclus évidemment.

L’innovation avec Grails est un sujet passionnant, qui sera de nouveau abordé dans une session de l’Université du SI les 1 et 2 juillet prochain. Décidément, le suspense se poursuit…

Extrait du code de génération du flux RSS à partir du plug-in Grails « Feeds ».

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

render(feedType:'rss', feedVersion:'2.0') {
title = "Les propositions commerciales OCTO"
description = "La mise à jour régulière propositions commerciales d’OCTO"
link = url + "/wS/feedMissions"
 
// méthode du Core Domain pour récupérer les dernières modifications
// sur les missions. La variable period fournie par l’utilisateur permet de
// remonter les modifications chaque jour (défaut) ou chaque semaine.
def l = Project.listRecent(period, new Date())
 
l.each { pr ->
  // On filtre sur les projets facturés
  if (pr.isBilledProject()) {
    def client = "client non renseigné"
    def sector = "secteur inconnu"
 
    if (pr.client) {
      client = pr.client.name
      sector = pr.client.sector.name
    }
 
    // projectStatus.name renseigne sur l’état de la mission :
    // avant-vente, signée, annulée, perdue…
    def title = pr.projectStatus.name.toUpperCase() + " : " + client + " (" + sector + ")"
    def ref = pr.getReferenceAndName()
    def am = pr.accountManager ? pr.accountManager.trigram : "N/A"
    def invoice = pr.invoicingType.description
    def amount = pr.totalAmount() ? String.format('% 6.2f', pr.totalAmount()) + " euros"
                                  : 'N/A'
 
    // Définition d’une entrée RSS
    entry(title) {
      publishedDate = new Date()
      link = url + "/project/edit/" + pr.id
 
      // cette méthode met en forme les informations
      // sous forme linéaire ou tabulaire, selon le choix utilisateur
      renderFeed([ref, invoice, amount, am, pr.comment], format)
    }
  }
}

(*) Hmm… Ce n’est pas entièrement vrai, à croire que l’adage sur les cordonniers a la nuque raide

Suggestion d'articles :

1. La productivité des développements… n’est pas qu’une affaire de technologie !
2. Scrum sans itérations ?

Tout projet de développement implique des choix d’architecture. Quels patterns de code ? Quels outils de build ? Un projet innovant place ces question sur un axe temporel : les réponses adaptées ne sont pas les mêmes entre la 1ere itération et la 20ème itération. Une architecture « dynamique » permettra de maximiser la valeur apportée par une architecture applicative à un moment donné d’un projet.


D’abord les bleus et autres hématomes du développeur et de l’architecte d’application. Qui n’a jamais ressenti une certaine gêne en expliquant au client, au bout d’une 1ere itération de 2 semaines, que l’essentiel des stories n’est pas livré parce que  » la mise en place du build a pris plus de temps que prévu  » ou encore  » le département intégration n’a pas livré la base Oracle de dev à temps  » ?

Plus pernicieux (faut regarder sous le capot), qui n’a jamais pesté sur le temps perdu à coder des mappings objets métier->DTOs fastidieux et totalement passe plat (même propriétés du model métier au DTO) !

Il ne s’agit pas de remettre en cause les patterns et outils évoqués dans ces exemples mais plutôt de se questionner sur le timing optimal pour leur introduction dans un projet innovant. Entendons-nous un minimum sur les termes : un projet innovant signifie à minima un métier flou, non maîtrisé par la MOE (et parfois par la MOA…) tandis que dynamicité de l’architecture d’application recouvre les changements d’outis, de pratiques et de patterns au cours du projet.

Des principes à leur mise en oeuvre

Les agilistes ont introduit la notion de design incrémental qui reçoit des échos positifs des architectes d’application. Pourtant la traduction dans les choix d’architecture et les pratiques de développement sur les plateaux projets, tarde encore à se concrétiser. Les principaux axes de l’architecture dynamique sont le build, l’intégration et surtout les formes de code. Je citerai des exemples concrets sur la base du framework Grails. Au passage, je suis très preneur d’exemples équivalents sur des framework de spectre de fonctionnalités équivalents (SEAM, Rails…).

Dynamique de build

Configurer 4 projets maven dans la première itération semble parfois inepte, quand dans ces premiers jours les dépendances externes sont minimums, que chaque couche contient quelques classes seulement et qu’on a pas avancé d’un iota sur le domaine métier !

Dans le cas d’un développement sur Grails, les 1ere itérations peuvent faire l’impasse sur l’outil de build  » entreprise  » pour utiliser directement les scripts du framework. Les quelques dépendances de la première itération seront simplement déposées dans le répertoire  » lib  » de l’application. Si l’appli Grails utilise une approche  » blended « , c’est-à-dire avec des appels à du code java, on mettra en place un seul et unique artifact maven.

Quels déclencheurs pour dépasser cette première  » proto-archi  » de build ? Le projet avançant, ce n’est plus 2 ou 3 dépendances externes mais 10, 20, qui vont s’ajouter, avec une gestion de version de plus en plus fastidieuse : c’est là que maven fait sont entrée fracassante, sous les houra de la foule en liesse.

Dans le cas des couches (des artifacts buildés) la séparation des responsabilités et la réutilisation seront les principaux facteurs poussant à l’éclatement d’une couche applicative en plusieurs.

Dynamique d’intégration

Minimiser le coût de l’intégration des premières phases a été grandement simplifié par l’outillage récent. Les vieux loups de mer du design incrémental tenterons de nous vendre la quintessence de la simplicité avec une  » persistence fichier  » pour les 1ères itérations : je dis tu bluffes Martoni et je demande à voir.

La facilité de mise en place et d’utilisation des bases in memory permet maintenant de ne pas avaler d’un seul coup un gros morceau indigeste du nom d’Oracle ou Sybase. Dans le cas de Grails, HSQLDB est bundlé et configuré par défaut comme datasource : coût de la mise en place = 27 secondes.

Un apport plus novateur de Grails est le script BootStrap.groovy qui permet par exemple d’injecter très rapidement des données métier au démarrage de l’application, en bénéficiant des raccourcis de GORM et en évitant de mettre en place un import SQL ou DBUNIT.

Mon graphe d’objets se complexifiant, mes volumes de données augmentant, je passerai tôt ou tard sur la techno cible, avec des bons vieux insert sql pour la reprise des données…

Dynamique de pattern de code

Cet axe de l’architecture dynamique est plus excitant encore, car invisible pour qui n’a jamais mis les yeux sur le code. Les perspectives d’amélioration de la productivité sont très importantes dans ce domaine.

Les DTOs

Maximiser le feed-back client c’est aller vite dans la livraison de fonctionnalités, en minimisant notamment l’entropie, i.e. le volume de code inutile. Dans les premières itérations il s’agit souvent de remonter jusqu’à la GUI les  » proto-objets  » métier pour valider une compréhension du domaine avec le client. Or quoi de plus inutiles (donc coûteux) que des DTOs passe plats, depuis qu’hibernate permet de remonter jusqu’à la GUI des objets métier ? Accessoirement, coder des DTOs passe plat est une des activités de dev les plus déprimante qui soit sur terre.

Qu’on ne me fasse pas de procès d’intention, le pattern DTO n’est pas près de disparaître. Le métier et la GUI allant en se complexifiant au cours du projet, il refera surface au premier formulaire calqué sur plusieurs objets ou alors dès que des composants GUI riches et réutilisables seront nécessaires…

Si vous utilisez Grails vous vous contenterez d’abord d’afficher les POJOs métiers dans la GUI, par exemple ${book.author.name}. Puis petit à petit vous introduirez des  » command objects  » pour les formulaires complexes.

Les DAOs

Hibernate facilite grandement l’accès à la base, à tel point qu’on se surprend à voir la base comme un vrai repository d’objet. L’écriture d’un DAO sur des requêtes simples conduit souvent à des classes et des méthodes anémiques, qu’on hésite à fondre dans le service métier pour limiter le nombre d’entité. Du coup exit le DAO, on mélange allègrement la persistence et la logique, le code résultant restant propre et testable tant que les requêtes restent simples.

Vous avez pigé le truc, tôt ou tard le code d’accès aux données se complexifiera et son externalisation de la logique métier deviendra inévitable. L’autre facteur de décorrélation DAO/logique métier sera la testabilité de la logique métier, grandement simplifiée si le service prend en paramètre des POJOs remontés de la base au runtime ou construit manuellement au test time.

Dans le cas de Grails une évolution typique du code d’accès aux données est la suivante :

1. Grâce à la puissance de GORM (n’ayons pas peur des mots), je mets facilement du code d’accès à la base dans mes controlleurs Grails.
2. La logique métier dépasse le CRUD et je l’externalise dans un service (Java ou Groovy) qui accède directement aux objets en base.
3. Le bigniou se complexifie encore et la logique d’accès à la base et la testabilité du tout m’incite à séparer logique métier et DAO.

DTOs et DAOs sont des exemples emblématiques de ces patterns qu’ils faut savoir embrayer et débrayer au moment opportun, mais d’autres pattern sont là, à attendre un timing optimal.

Conclusion

Les principes exposés ici (architecture itérative et incrémentale) ne sont pas des scoops, loin de là. En revanches, les frameworks récents permettent de les appliquer concrètement sans trop d’effort des équipes et surtout sans rupture technologique forte au cours du temps. Le prototype des premiers jours n’est plus en PHP ou pur HTML mais en MVC, la persistence des premiers jours n’est plus en  » fichier  » mais en base relationnelle. On ne cassera jamais tout pour jeter un investissement conséquent.

La dynamicité de l’architecture prend en compte le facteur temporel que revendique le pattern zone innovation->zone rationalisation. En revanche le facteur temps des exemples abordés ici situe ces évolutions dans la seule zone d’innovation : ces nombreux changements doivent intervenir dans les itérations de développement seules, bien avant le passage en TMA !

Plusieurs postulats implicites n’ont pas été explicités en début de post :

- la qualité interne (invisible du client) n’est pas négociable. Les patterns  » légers  » des premières itérations ne doivent pas nuire à la robustesse, la lisibilité et la testabilité du code.

- l’architecture dynamique n’est pas compatible avec la cascade. Les outils et les patterns calquent leurs évolutions sur le recueil du besoin et les feed-backs client, au fur et à mesure des itérations.

- les développeurs et architectes en charge du projet sont compétents, responsabilisés et courageux.

Compétents parce qu’ils connaissent les différentes approches accessibles et la pertinence de chacunes.

Responsabilisés parce que les patterns émergent de leur activité quotidienne et qu’ils n’attendent pas les 2 heures de support hebdomadaire de l’expert pour remettre en cause leur archi.

Courageux parce qu’ils challengent en permanence leur architecture applicative en reconnaissant que les décisions d’hier ne sont plus les bonnes aujourd’hui ou que l’archi de demain équivaut à un sur coût aujourd’hui.

Gilles Laborderie et moi-même présenteront des exemples de dynamicité d’architecture pendant la conférences Grails eXchange. Voir à ce sujet aussi les autres sujets OCTO.

Suggestion d'articles :

1. Architecture d’intégration basée sur un pattern Médiateur
2. Paris JUG : Groovy et Grails
3. Grails Maven Plugin 0.3

Mars 2006. La comète Grails fait son entrée dans la galaxie Java en sortant sa première version publique. Inspiré par le succès du framework Ruby on Rails, Grails propose alors d’en adapter la recette à la sauce Java. Sa promesse ? Fournir une solution simple, rapide et élégante pour développer des applications Web J2EE pour l’entreprise.

Mars 2007. A quelques jours du premier anniversaire du framework, force est de constater que l’engouement autour de Grails reste intact. Chez OCTO comme chez nos clients, de premières références significatives voient le jour en production. On commence à y croire : Avec Grails, ca va vite.

Grails venant enrichir une panoplie de solutions déjà à notre disposition pour nos développements Web, des questions se posent : Choisir Grails, pourquoi pas, mais dans quels cas ? Est-il adapté aux contraintes d’un SI d’entreprise ?

Dans quels contextes et de quelle manière Grails peut-il faire la différence ?

L’approche  » Grails Intégrale  » pour démarrer rapidement des applications Web

Grails nous propose une solution packagée pour mettre en oeuvre une application Web. De l’IHM à la donnée, Grails permet à n’importe quel développeur Java peu expérimenté de délivrer rapidement ses premiers écrans Web. Pour cela le framework s’appuie sur plusieurs concepts clés d’amélioration de la productivité ; on retiendra notamment le fameux paradigme  » convention over configuration  » qui permet de minimiser le  » code technique  » au profit du  » code métier « . Il en résulte une réduction du ticket d’entrée généralement constaté au démarrage d’applications JEE.

Avec Grails on peut donc développer rapidement des prototypes Web. C’est bien… mais avouons que depuis longtemps des technologies comme PHP répondent très bien au besoin. Enfin, jusqu’au jour où la petite application veut devenir grande. Car si aujourd’hui je veux minimiser les contraintes pour sortir rapidement un prototype isolé, demain je le voudrais maintenable et exploitable par des tiers, interopérable et respectant les contraintes d’architecture du SI. D’ici là, on cherchera à minimiser la période et les coûts de transition.

C’est ici que Grails prend toute son ampleur. Sa force ? Résister aux deux temps qui composent la vie d’une application : L’innovation et la rationalisation. En choisissant Grails pour mes prototypes, je suis rassuré. Je sais que contrairement à Struts, il me fournira d’abord toute la souplesse et la légèreté dont j’ai besoin pour affiner ma compréhension du métier au fil du projet sans avoir la sensation de courir un 100 mètres dans un champ d’argile. Au final, peut-être que cette approche légère suffira alors pour répondre parfaitement à mon besoin. Mais je sais aussi qu’à tout moment je serai capable de faire évoluer couche par couche mon application vers une architecture JEE plus classique. Le framework encapsulant des composants et patterns JEE standards (Hibernate, Spring, JUnit, Sitemesh…), une simple adaptation du code suffit. Nul besoin de réécriture complète et de transition couteuse. Chez OCTO, on parle alors de  » cristallisation  » ou de  » refroidissement  » des couches de l’application.

Les motivations de cette cristallisation peuvent être de plusieurs natures. Liées à des contraintes externes au projet telles que la volonté de standardisation des technologies et des architectures applicatives au sein d’un SI, le besoin d’intégration avec une application existante ou encore la volonté des équipes de TMA de rester sur du 100% Java. Mais aussi liées à des besoins propres au projet tels que l’apparition de besoins techniques très spécifiques, sortant du cadre du  » tout Grails « , ou encore par l’agrandissement de l’équipe projet. Car il faut avouer qu’à ce jour si l’approche  » Grails Intégrale  » convient parfaitement aux petites équipes (moins de 4 développeurs) et aux petits projets, il deviendra délicat de se passer d’un socle Java outillé lorsque le projet prendra de l’ampleur. Malgré de premiers plugins, le faible support de Grails par les IDE Java tels Eclipse ou IntelliJ IDEA est à l’heure actuelle pénalisant en termes de refactoring et de contrôle de validité du code. Du coté de la communauté Grails, semble-t-il que ce point ait été fixé comme l’une des priorités d’amélioration à court terme ; des travaux sont en cours, à suivre…

L’approche  » Grails IHM  » pour booster la couche IHM des applications Java JEE

Nous avons vu que la modularité de Grails lui permet d’accompagner le cycle de vie d’une application, depuis son démarrage en  » Grails Intégrale « , jusqu’à sa transformation en une application mixée Grails/Java. Est-il pertinent d’utiliser cette modularité pour envisager une utilisation de Grails  » à la carte «  pour prendre en charge uniquement la couche IHM d’une application bâtie sur un modèle Java JEE classique ?

Grails peut être utilisé uniquement comme un framework d’interfaces WEB au même titre qu’un Struts, qu’un JSF ou qu’un GWT. Dans ce contexte là, seules les couches vue/contrôleur de la bête seront sollicitées, le reste de l’application s’appuyant sur un développement Java classique. A quoi bon ? « Yet Another Web Framework » diraient nos amis d’outre-Atlantique… Certes. Mais quel framework !

De manière générale, la productivité de développement d’un écran est élevée ; la communication entre les couches se fait trivialement,  » convention over configuration  » toujours, le système de  » reloading  » à chaud permet d’aller très vite dans le processus de développement, la gestion des  » taglibs  » est excellente et favorise la production de code propre et réutilisable. Au delà de cette productivité, le positionnement de Grails vis-à-vis des frameworks concurrents peut être rassurant pour beaucoup. Contrairement à GWT qui introduit un nouveau paradigme maison pour gagner en productivité, Grails conserve un modèle et des concepts bien familiers. Après quelques minutes d’utilisation on comprend rapidement que du simple CRUD jusqu’aux écrans de navigation complexes et sécurisés, Grails ne sera jamais limitant. Au contraire, sa productivité prendra tout son sens avec l’arrivée d’écrans complexes.

Ajax bien sur… Grails propose une encapsulation native de certaines fonctionnalités des frameworks Prototype, Dojo et Yahoo!UI. Recharger dynamiquement le contenu d’une page devient alors aussi facile que de saisir une taglib dans une page JSP. Cependant, ne nous voilons pas la face, l’application s’étoffant il devient difficile de se passer de l’utilisation de JavaScript et de ne pas sortir du cadre Ajax de base proposé par Grails. Malgré tout, cela se fait très bien et encouragé par le confort général de développement lié à l’utilisation de Grails on se surprend à faire du client Riche ; les écrans sont sexys et gagnent en expérience utilisateur.

Suggestion d'articles :

1. Transactions et traitement métier en Grails
2. Grails Maven Plugin 0.3
3. OCTO à la conférence Grails eXchange 2007