Bonjour,
j'aimerai comprendre le réelle apport de Seam ?
Si j'ai bien compris Seam permet de relier directement une page JSF à un Bean (EJB 3) ou les apports sont-ils autres d'avance merci.
Version imprimable
Bonjour,
j'aimerai comprendre le réelle apport de Seam ?
Si j'ai bien compris Seam permet de relier directement une page JSF à un Bean (EJB 3) ou les apports sont-ils autres d'avance merci.
S'en passez des BackingBeans me semble d'une grande utilité puisque ça permet d'éviter une "couche supplémentaire"!
Utilisation des annotation: Même si beaucoup de programmeur préfèrent l'utilisation des fichiers xml pour la configuration "faces-config.xml", personnellement je me trouve à l'aise avec les annotation.
La productivité essentiellement, Seam apporte un réel gain de temps de développement.
Les mécanismes apportés, et la facilité de développement de composants réutilisables sont déconcertants une fois qu'on a pris le coup.
Je rajouterais aussi l'intégration : Seam intègre nativement EJB3, JSF, Hibernate/JPA, Richfaces ou IcesFaces au choix, Drools, Jpbms, la gestion des pageflow/workflow tout ça sans rien faire. Or quant on a tenté de faire marcher rien que 3 de ces éléments ensemble, soit même sans aide c'est vraiment laborieux.
La gestion des transactions sur des composants plus léger que les EJB, les composants Seam sont transactionnels ce n'est pas rien.
Le mécanisme de bijection : injection et outjection de dependance par les annotations @in et @out en précisant le scope pour l'outjection.
Pour l'injection seam se debrouille tout seul avec le nommage des objets grâce à ce qui est fait en outjection ou avec l'annotation @Name.
Ce mecanisme est dangereux car beaucoup ont tendance à travailler à l'ancienne en mettant tout dans la session, mais si on utilise proprement les contextes et en particulier la conversation que j'aborde après il deviens très puissant, et facilite grandement le travail.
Enfin actuellement, quelque soit le langage pour gérer l’état conversationnel dans une application Web il n’y a qu’une seule solution : stocker les informations dans la session HTTP, ce qui entraine de nombreux problèmes de purges des informations et de ré initialisation.
Seam a alors introduit la notion de conversation longue, définie soit de manière implicite avec des EJB de type Stateful, soit de manière explicite en déclarant le contexte de la conversation. Le développeur peut ainsi choisir à quel moment commence la conversation et à quel moment elle se termine.
Le premier exemple cité dans la documentation de Seam pour convaincre à son utilité est très parlant pour comprendre l’intérêt, par exemple, de la conversation :
Prend le cas d’un site web de réservation d’hôtel, si l’utilisateur a ouvert deux onglets sur le site et parcours les informations de deux hôtels différents, les informations visualisées par l’utilisateur sont stockées dans la session. Maintenant admettons qu’il trouve un hôtel à sa convenance, il va effectuer la réservation. S’il retourne sur son autre onglet, il risque probablement d’avoir des valeurs tout à fait fausse affichés à l’écran car il y a de forte chance, comme sur la majorité des sites web bloqués aux contextes de bases de stockages des objets (Request qui ne va maintenir aucune donnée, page qui va perdre les données dès que l’utilisateur change de page, et session qui sert un peu de décharge à tout ce qui doit être conservé plus longtemps que la page).
Seam résout donc ce type de problème grâce à la conversation, on peut désormais programmer un composant avec à état conservé en ayant la certitude de n’avoir aucun problème d’accès concurrent ou d'ambiguïté de contextes.
+1 pour Mikrob
En particulier pour les applications Ajax, le scope request est trop court et le scope session est trop long. Il en fallait donc un ou plusieurs en plus : conversation, mais aussi page (façon seam).
A noter que Seam n'est pas le seul à apporter ces scopes supplémentaires, Shale fait de même. Ce qui prouve au moins que c'était un vrai besoin.