Cependant, en référence à ton précédent commentaire, je pense que MVC s'applique sans problème aux applis Web (et c'est une bonne chose de l'appliquer). Modèle = ensemble des classes définissant ton modèle (ok, c'est une définition récursive, mais c'est aussi une évidence) / Vue = les pages web/JSP / Contrôleur = le lien entre les deux, c'est à dire les classes qui définissent la logique de ton appli, la réponse aux actions de l'utilisateur, etc.
Tu demandes où sont les listeners: le rôle d'un listener est de déclencher un traitement dans le contrôleur en réponse à une action de l'utilisateur. Dans une appli web (pour rester simple) l'action d'un utilisateur peut être l'activation d'un lien ou le clic sur un bouton dans un formulaire. Donc de manière générale, le listener est implémenté par l'adresse URL (et les paramètres passés dans la requête). Dans le cas de Struts, c'est le paramètre action (HTML ou taglib) des forms, les paramètres de la requête, et le fichier de config (qui définit le mapping entre un URL et une classe).
Pour ce qui est du framework Struts, je pense tout simplement que l'implémentation est foireuse.
Par exemple (et je me contente de citer Rod Johnson -- qu'on a mentionné plus haut), l'un des problèmes de Struts est qu'on doit étendre une classe de base (la plupart du temps Action). C'est d'ailleurs une question dans la FAQ est la réponse est du genre: "oui c'est effectivement gênant, mais c'est comme ça et c'est trop compliqué de le changer maintenant". A mon avis, si le framework ne change pas, les développeurs vont changer de framework, voilà tout!
L'autre gros problème est, effectivement, le fichier de config: la séparation des concepts evoquée plus haut par gc est bénéfique en effet. Le hic c'est que les Actions et le fichier de config recouvrent pour une partie la même logique: le contrôleur. Par ailleurs pourquoi avoir un fichier de config? On ne va pas le changer à l'exécution! Avoir les classes et le fichier de config introduit un risque: le développeur doit veiller à garder les deux synchronisés.
Le détail de l'implémentation ou les solutions ne sont pas toujours géniaux. Je me suis retrouvé plusieurs fois dans une situation où je suis resté perplexe face à l'implémentation.
Par exemple, l'action LookupDispatchAction se base sur le libellé internationalisé du bouton et opère un lookup inversé (i.e. utilise la valeur pour retrouver la clé) dans le fichier de ressource afin de déterminer le nom indépedant du language. Quid si deux boutons aux fonctions différentes ont le même libellé? Ok, je ne cherche pas une solution, je dis simplement que le concept dans ce cas est idiot!
Je ne dirai rien au sujet de la taglib, je pense que tout a été dit par d'autres.
[^] # Re: Struts or not ?
Posté par Bertrand D . En réponse à la dépêche Conception et déploiement J2EE - Critique du livre. Évalué à 4.
Cependant, en référence à ton précédent commentaire, je pense que MVC s'applique sans problème aux applis Web (et c'est une bonne chose de l'appliquer). Modèle = ensemble des classes définissant ton modèle (ok, c'est une définition récursive, mais c'est aussi une évidence) / Vue = les pages web/JSP / Contrôleur = le lien entre les deux, c'est à dire les classes qui définissent la logique de ton appli, la réponse aux actions de l'utilisateur, etc.
Tu demandes où sont les listeners: le rôle d'un listener est de déclencher un traitement dans le contrôleur en réponse à une action de l'utilisateur. Dans une appli web (pour rester simple) l'action d'un utilisateur peut être l'activation d'un lien ou le clic sur un bouton dans un formulaire. Donc de manière générale, le listener est implémenté par l'adresse URL (et les paramètres passés dans la requête). Dans le cas de Struts, c'est le paramètre action (HTML ou taglib) des forms, les paramètres de la requête, et le fichier de config (qui définit le mapping entre un URL et une classe).
Pour ce qui est du framework Struts, je pense tout simplement que l'implémentation est foireuse.
Par exemple (et je me contente de citer Rod Johnson -- qu'on a mentionné plus haut), l'un des problèmes de Struts est qu'on doit étendre une classe de base (la plupart du temps Action). C'est d'ailleurs une question dans la FAQ est la réponse est du genre: "oui c'est effectivement gênant, mais c'est comme ça et c'est trop compliqué de le changer maintenant". A mon avis, si le framework ne change pas, les développeurs vont changer de framework, voilà tout!
L'autre gros problème est, effectivement, le fichier de config: la séparation des concepts evoquée plus haut par gc est bénéfique en effet. Le hic c'est que les Actions et le fichier de config recouvrent pour une partie la même logique: le contrôleur. Par ailleurs pourquoi avoir un fichier de config? On ne va pas le changer à l'exécution! Avoir les classes et le fichier de config introduit un risque: le développeur doit veiller à garder les deux synchronisés.
Le détail de l'implémentation ou les solutions ne sont pas toujours géniaux. Je me suis retrouvé plusieurs fois dans une situation où je suis resté perplexe face à l'implémentation.
Par exemple, l'action LookupDispatchAction se base sur le libellé internationalisé du bouton et opère un lookup inversé (i.e. utilise la valeur pour retrouver la clé) dans le fichier de ressource afin de déterminer le nom indépedant du language. Quid si deux boutons aux fonctions différentes ont le même libellé? Ok, je ne cherche pas une solution, je dis simplement que le concept dans ce cas est idiot!
Je ne dirai rien au sujet de la taglib, je pense que tout a été dit par d'autres.