J'aimerai ici faire un billet pour faire une petite mise au point. Les frameworks "productifs" type RoR, Grails, Play! et j'en passe ont clairement le vent en poupe. L'idée au combien louable, est bien sûr d'automatiser au maximum les tâches rébarbatives du développeur lorsqu'il s'attaque à une application web. J'imagine que toute cette mouvance a pu naître d'un écoeurement bien naturel vis à vis des piles ou frameworks plus anciens, comme Struts, toute la pile JEE et même ASP.NET avec ses bons vieux WebForm.

Ce qui me chagrine dans l'histoire, c'est que philosophiquement, je suis de tout coeur derrière ces idées de simplifications : je n'ai jamais pu encadrer le xml au kilomètre de Spring à l'époque, les Web Form me faisaient faire des cauchemars tant leur opacité était grande et je n'ai jamais été pour une multiplication des couches sans une grande nécessité.

Ceci dit, ne jetons pas le bébé avec l'eau du bain. Je m'explique. Pour paraphraser Eric Evans dans DDD, la complexité d'une application réside dans le métier qu'elle tente de représenter. Comment cela se traduit? Pour moi, cela veut dire que quelque soit les frameworks que j'utilise, ils ne devront jamais entamer ma capacité à modéliser le métier. Le succès, la richesse et l'efficacité de mon application dépendent essentiellement de ma capacité à capter la subtilité du métier. Comment mettre le maximum de chance de mon côté? En développant le modèle en isolation de tout autre considération, à l'aide d'une approche objet, d'un bon framework de tests unitaires et de bons outils de refactoring. La présentation, la persistence, le cache, tout le reste est superflu et doit le moins possible, voir pas du tout, impacter mon domaine.

Bref, après autant de blabla, voilà donc enfin ce qui me chagrine dans ce que j'ai pu voir des quelques frameworks productifs que j'ai essayé : ils sont invasifs. Le choix d'Active Record pour la persistance est une friction dans le développement du métier, car la persistance n'est alors plus transparente. Pour respecter le principe de responsabilité unique, vu que les "entités" gèrent la persistance, nous devons développer les véritables objets métier à part, et ils doivent agréger alors ces entités. Cela implique une complexification non négligeable du développement du domaine. Du coup, beaucoup des exemples que j'ai pu observer se contentent de montrer une application CRUD, avec un métier anémique contenu dans les contrôleurs, mais aucune application n'est réellement du CRUD au final.

La véritable productivité est liée à la maintenabilité, et la maintenabilité est très liée à l'isolation du métier (et aux tests bien sûr :) ). Oui du coup, avec cette philosophie en tête sur Tiron, nous n'avons pas choisi un de ces beaux frameworks à la mode, et nous avons du construire notre propre pile (jQuery/Restlet/Freemarker/Hibernate pour les curieux), et je pense que notre productivité actuelle en considérant la complexité du métier que nous devons gérer n'a pas à pâlir face à la concurrence.

P.S : je ne suis pas un expert de ces frameworks je l'avoue. Si quelqu'un peut me démontrer le contraire de ce que j'avance, j'en serai très heureux.