Discussion :

[srenaudo]

Bonjour,

Je travaille actuellement un projet où l'intégration d'un ancien framework périmé doit être supprimé au profit d'une solution plus à jour.

Le projet basé sur un fonctionnement proche du MVC "ancienne version" réuni plus de 1000 fichiers, de nombreuses classes et de nombreuses JSP.
Il y a aura très probablement l'intégration d'EJB prochaine afin de se débarasser de couches CICS / COBOL.

Je retombe souvent sur Spring et Struts, sans trop d'autres formes de concurrences.
Je préfèrerai qu'on évite les querelles de chapelle, mais quelles sont les solutions qui vous paraitraient les plus adaptées et les plus à jour ?

Cordialement.

[elitost]

STRUTS , surtout car tu trouveras une grosse communauté qui t'aidera...

[dlemoing]

Struts a une grosse communauté.
Spring a une communauté grandissante mais surtout un meilleur design.

[srenaudo]

Merci pour vos réponses, on reste donc dans le lot de solutions habituelles.

Spring a une communauté grandissante mais surtout un meilleur design.

Qu'entends tu par "meilleur design" ? Quels spécificités t'amènent à cet avis ?

[Shivan]

Et puis y à JSF aussi. A terme ça devrait remplacer STRUT. Par contre la communauté autour de JSF est plutot mince. tu auras du mal à trouver de l'aide.

[ego]

Pour SPRING, le "meilleur design" est surtout dû à une meilleure séparation des responsabilités au niveau des différents éléments du MVC.
Par exemple, avec SPRING, tu peux aussi faire du Struts, JSF, WebWork, Tapestry, XML, PDF, Excel,...Bref, le concept de vue est très général ce qui permet de mixer plusieurs technos de rendu.
Tu bénéficie en plus de l'IoC pour configurer tes objets M et C, c'est donc pas mal.
Tu as aussi SPRING WebFlow pour encore mieux travailler sur l'aspect navigation (mais tu n'es pas obligé de l'utiliser)

[dlemoing]

Pourquoi un meilleur design MVC ?

M comme Model (ou comment fonctionne le data binding et la validation):
- Struts oblige à étendre une classe concrete ActionForm ce qui interdit la réutilisation de ton domain model et il est donc impossible de travailler directement avec dans ton html. On est obligé de faire le lien entre ActionForm et le domain.
- Spring permet de réutiliser le domain model
- je ne connais pas trop le fonctionnement des transformations pour des objets autre que des String ou des primitives mais il semble que ce n'est pas très fameux
- Spring fournit un support des PropertyEditor (voir norme JavaBeans)
- la validation dans l'ActionForm ne la rend pas réutilisable dans le reste de l'appli. La validation peut également se faire avec Commons Validator qui utilise une approche à base de XML mais pour ma part je trouve ca assez peu intuitif (question de gout).
- Spring s'appuie sur l'interface Validator pour la validation (des implémentations existent pour utiliser Commons Validator comme dans Struts)

V comme Vue :
- Struts fournit juste un support pour les JSP (il existe toutefois des librairies externes pour supporter d'autres technos : XML, Velocity)
- Spring s'integre avec de nombreuses technos pour la vue : JSP, Velocity, FreeMarker, XML/XSL, Excel, PDF
- Spring est facilement extensible et permet d'ajouter très simplement un support pour une autre technologie de présentation en respectant le principe du MVC.

C comme controleur :
- Les actions Struts (controleurs) doivent être threadsafe dans la mesure ou il n'existe qu'une seule instance de créée
- Par défaut, les controleurs de Spring sont uniques (et donc threadsafe) mais la liberté est laissée au développeur de changer ce comportement de manière déclarative
- L'ajout de fonctionnalités pour plusieurs controleurs de Struts doit se faire en utilisant l'héritage avec une classe abstraite mutualisant un certain nombre de comportements (manque de flexibilité, cf la deuxieme regle du GoF)
- Spring utilise des HandlerInterceptors pour qui ajoute des comportements avant et après l'execution d'un controleur (très flexible car déclaratif)
- Spring fournit plusieurs controleurs qui répondent aux cas les plus fréquents (formulaire, wizard, ...) et fournissent de nombreux points d'extensions qui ne laissent pas de doute sur comment bien les utiliser.


Autres points dont il faut tenir compte :
- Struts se dirige vers une approche plus orienté JSF (Shale) qui n'a plus grand chose à voir avec le Struts d'origine
- La branche 1.x ne devrait plus trop évoluée (en dehors de la maintenance)
- Personnellement (et je ne suis pas le seul), j'ai du mal à comprendre la stratégie de Struts à long terme
- Les ressources sur Struts sont par contre très nombreuses
- Spring ne se limite pas à un framework MVC et il y a de grande chance que tu deviennes plus efficace avec Spring MVC si tu l'utilises également pour les autres couches.


PS : j'ai 2-3 autres arguments mais je ne suis pas suffisament sur de moi en ce qui concerne Struts

[srenaudo]

Merci pour toutes ces précisions et arguments exposés qui plus est fort clairement !

Cela me fournit un bon début et des pistes très intéressantes pour débuter une étude détaillée et un comparatif entre Struts et Spring.

[Alwin]

Cela me fournit un bon début et des pistes très intéressantes pour débuter une étude détaillée et un comparatif entre Struts et Spring.

Si tu cherche à comparer les deux, sache que tu ne dois pas confondre Spring et Spring-MVC.

Spring a un spectre beaucoup plus large que celui de Struts qui lui, ne se limite qu'à de la présentation MVC dans un contexte WEB !

[dlemoing]

Pour ma part, je n'ai fait que la comparaison entre Struts et Spring MVC.
Spring a bien plus encore à offrir.