Affichage des articles dont le libellé est MVC. Afficher tous les articles
Affichage des articles dont le libellé est MVC. Afficher tous les articles

17 juin 2008

Je vote Spring @MVC


Depuis X mois, je tergiverse sur le framework web que je compte "pousser" pour remplacer le vieillissant Struts 1.x.

Suite à SpringOne08 où j'ai suivi la session de Keith Donald sur Spring MVC 2.5 (rebaptise "@MVC"), WebFlow et spring JS, je penche nettement vers cette solution.

Certes, le produit n'est pas révolutionnaire - on reste dans du MVC classique. Mais ...
  • Son principe général, comparable à Struts (MVC oblige), facilite l'apprentissage pour les développeurs Struts : on peut expliquer chaque notion en se référant à l'équivalent Struts, par exemple pour la librairie de tags.
  • Les conventions et annotations permettent de réduire très sensiblement la configuration, ce qui est très appréciable
  • Le mécanisme proposé par Web Flow est un très net avantage, permettant de faire des IHM robustes
  • La documentation est de bonne qualité, avec de nombreux exemples
  • La pérennité de l'outil ne fait pas de doute
  • L'intégration Ajax et le support des widgets Dojo permettent de faire une appli raisonnablement sympathique, sans nécessiter des développeurs JavaScript / web 2.0.
Pour des besoins plus "sexy", je pencherais pour GWT, ou Flex, mais pour mon appli actuelle, plus que classique dans son approche, mais destinée à durer (...), je préfère miser sur un cheval fiable et qui sera toujours d'actualité dans X années.
2 commentaires
Libellés : ,

15 décembre 2007

quel framework web pour l'avenir ?





Le constat est clair : fàce aux alternatives "modernes", Struts fait office de mammouth, au sens "pachiderme" du terme. Top de configuration et de classes à développer, même pour un simple hello world, alors pour coder une transaction de prise de commande étalée sur 5 écrans...

Problème, la relève s'avère un peu trop prolifique. Faut-il suivre Struts², Spring MVC - selon une approche assez classique - faire le pari des "Ruby-on-Rails-like" (Grails, Sails, Trails et j'en passe) ou encore passer à tout autre chose (Wicket ?). Sans évoquer l'option JSF, avec ou sans jboss Seam, ou Google Web Toolkit. Et pourquoi pas du pur HTML + JavaScript + services REST ?



Alors ? J'ai du mal a me faire une opinion tranchée, surtout que je n'ai mis en oeuvre aucun de ses frameworks à une échelle significative.

Un constat cependant : en tant que prestataire de service, je dois convaincre mon client du bien fondé d'un choix. Sails (au hasard) est peut être très bien, mais quel dirigeant en a entendu parler ?

Deuxième aspect, la taille de la communauté et/ou la documentation disponible. De ce point de vue, Struts2 et Spring MVC sont les plus vendeurs, avec Seam et GWT.

Troisième point, la capacité d'adaptation des développeurs. Exemple de Grails : même si Groovy n'est pas bien compliqué, ça fait un langage de plus à connaître, et de nombreux mécanismes "auto-magiques" à apprendre. De ce point de vue le duck-typing est sans doute super pour les cracks, mais surtout source de bugs et de difficultés pour les autres, qui préfèrent le bon vieux "ctrl+Expace" pour obtenir la liste des méthodes disponibles.

Enfin, les possiblités de sortie. Si le framework ne suffit pas, comment faire ?

De cette réflexion, de mon point de vue Struts2 sort grand vainqueur :
  • le simple nom "struts" est définitivement vendeur. Peut importe que le code n'ait rien à voir avec Struts 1, je sais que je n'aurais pas à batailler pour le vendre, ni à mon chef, no à mon client. Deux de mes plus gros soucis en moins ;-p
  • la communauté webwork était assez limitée, celle de Struts est énorme, même si une grande partie reste utilisatrice de la première mouture. La doc et les bouquins sur le sujet commence à s'étoffer, et devrait atteindre le seuil critique.
  • pour le développeurs lambda, passer à Struts2 va nécessiter de "désapprendre" Struts 1, mais comme struts 1 était trop souvent mal employé, ça ne sera pas si difficile ;-p. Le principe de base reste de type MVC, donc le fossé à franchir est raisonnable. Grails, JSF ou GWT nécessitent de revoir complètement les notions sur l'architecture d'une application web.
  • quand à dépasser les limites de Struts2, le nombre impressionnant de "plugins" qui viennent le compléter parle de lui-même. Déjà, smartURL (futur codebehind) nous promet de réduire au strict minimum la conf nécessaire. Scope nous apporte du Seam-like, avec le support des conversations et la "bijection" des données manipulés. REST permet de coder facilement des service web léger (je n'ai rien vu pour SOAP), GWT permet de s'intégrer avec une IHM GWT, etc.
L'avenir me donnera peut-être tort (je viendrais alors éditer cet article pour effacer toute preuve), mais parier sur Struts2 n'est probablement pas le pire des choix, même si ce n'est pas non plus le plus courageux.

Et JSF ? Un standard, ça devrait rassurer ! D'une part j'ai du mal à rentrer dans la logique de JSF (un peu compliqué tout ça), d'autre part je n'aime pas du tout les JSP "à la JSF", totalement illisibles à mon gout. Et avec Facelets ? Pour être honête, Facelets + Seam serait mon second choix, disons plus "engagé" que le très sage "passons de Struts 1 à Struts 2".

Pas simple tout ça ... d'un autre côté, on ne pourra pas se plaindre d'être forcé à utiliser une solution, comme c'était le cas avec ces magnifiques EJBs 1.x qui m'ont tant fait râler.
2 commentaires
Libellés : ,
Inscription à : Articles (Atom)