Architecture de JBoss Seam

J'ai entendu dire beaucoup de bien de Seam et à la lecture du tutorial Seam, je commence effectivement à trouver ce framework pas mal du tout.

Toutefois, l'architecture Seam me surprend :roll:
Dans le monde j2ee, on est quand même habitué à une séparation des couches (ihm <-> service <-> dao et notament à présence de la couche service que je trouve indispensable.
Or dans les exemples du tutoriel, je ne retrouve pas la couche service 8O

Je n'en suis qu'au début de mon apprentissage de Seam mais la déjà je bloque sur le principe...

Bonjour et :king: pour avoir évoqué ce point de détail là!
Tu as osé dire tout haut ce que je pensais dans mon for intérieur ... :mrgreen:

Bref, moi aussi je me trouve dans la même situation. Je suis en train de me battre avec Spring 2.5 pour faire fonctionner Tomcat / Toplink / JPA / JSF dans une même application et je n'y arrive toujours pas.
J'avais entendu parler de Seam et de comment il simplifiait tout ça, mais ce qui me bloquait était justement la non-séparation des taches qu'il prone (IMHO).

Un ténor de Seam peut-il éclairer nos lanternes ?
:merci:

je viens de commencer à lire la documentation de référence de seam, que je trouve bien jusqu'à présent, pour le petit blem que vous avez remonté, à mon avis , on peut toujours utiliser une couche itérmédiaire pour les service, en utilisant des sessionbean ou autre, que tu invoque depuis l'action.

oui certainement qu'on peut rajouter la couche service mais ce que je trouve malheureux c'est que ce ne soit pas par défaut dans les exemples
De plus, le module Seam Gen que je trouve d'ailleurs assez impressionnant, n'inclut pas non plus de couche service. Ce qui gache un peu quand même :?

Seam s'appuie en effet sur une architecture 2 tiers. Exit donc la couche services ! 8O

J'utilise depuis quelques jours maintenant Seam 2.0.0GA mais l'architecture me pose quelques problèmes. En effet Seam gen me génére un nouveau projet vierge avec deux répertoires sources Actions et Models. Mes beans Entites sont donc stockés dans le répertoire/package Models et mes actions, bean managés dans le répertoire Actions.

Cependant j'ai des classes utilitaires comme le cryptage d'un mot de passe mais je ne sais pas ou les mettre !! Il ne s'agit pas ici d'un bean ni d'un bean entité ....

Quelqu'un peut donc m'aider sur ce point ?? 8-)

Citation:

---

Envoyé par anicaise

Seam s'appuie en effet sur une architecture 2 tiers. Exit donc la couche services ! 8O

---

Je n'ai pas encore fait de réelle plongée dans Seam, mais les quelques lectures que j'ai faites sur le sujet me permettraient plutôt de douter d'une telle affirmation. Seam est un web framework qui s'appuie sur les technologies JSF et EJB 3.0, et la couche EJB 3.0 constitue donc la couche service permettant de bénéficier de la gestion transparente des transactions, de la persistence JPA, de la sécurité, etc., comme dans une application classique multi-couches intégrant des ejb. L'objectif de Seam est surtout de faciliter l'intégration de ces couches, et en cela il se présente comme un concurrent direct au framework Spring.
http://www.theserverside.com/tt/arti...sSeamFramework

En tout cas, moi je ne vois pas ce qui dans l'architecture de Seam ferait penser qu'il n'y aurait pas de couche service, a priori, puisque les ejb constituent la couche métier, et dans tous les exemples Seam on parle des session beans. Donc je pense que ça dépend plutôt de l'architecture de sa propre application.

Salut tout le monde,

Je m'immisce dans la conversation pour donner mon avis sur le sujet.

Je suis vraiment beaucoup plus plongé dans le monde de Spring, et je ne connais Seam que superficiellement. Je viens de lire les deux liens fournis dans ce fil de discussion en diagonale ( suite à un renvoi que djo.mos sur un autre thread :) ) et j'ai quelques remarques.

Une chose qui me gène énormément : la configuration via des annotations. J'aime beaucoup avoir ma configuration dans des fichiers XML, et avoir des pojos simple pour mes différentes couches, ce que le "design" de Spring prône. Pourquoi vouloir à tout prix avoir des classes Java qui gère deux choses différentes ( configuration et logique ) ?

Ensuite, peut-être que mon parcours des liens donnés était trop rapide, mais je confirme que je n'ai vu aucune mention à une quelconque "couche métier". Les objets dits "métiers" semblent être un mélange de DAO et de Service classiques. La séparation des couches est essentielle pour permettre une évolution facile vers d'autres framework de persistence sans perdre la logique métier. Hors là, je vois mal comment on pourrait le faire...

Donc, pour résumé, voici ce que je pense de ma première vision rapide de Seam :

Avantages :
:arrow: rapidité de développement. Quand on voit la taille des codes sources donnés en exemple et les fonctionnalités qu'ils implémentent, on ne peut qu'admettre que ça a l'air plutôt facile à appréhender.
:arrow: configuration via les annotations : je mettrais ce point aussi dans les inconvénients, mais il est vrai que certaines personnes peuvent aussi apprécier d'avoir à la fois la configuration et la logique dans un même listing. De plus ça peut aider pour le refactoring.
:arrow: intégration avec les standards J2EE : Seam parait forcer l'utilisation des standards, ce qui dans l'ensemble est une bonne chose pour le futur, et pour la portabilité. jpa :)
:arrow: outils de developpement : les outils mis en place paraissent simples et efficaces dans la génération de code.

Inconvénients :
:arrow: où est passée la couche service ? :aie: peut-être qu'il faudra attendre un peu pour qu'avec le retour sur l'experience on voit de nouveaux patterns afin de bien gérer ce type de projet avec une meilleure séparation des couches.
:arrow: la configuration via les annotations : je cite ceci dans les inconvénients aussi, car j'adore le coté "mon Pojo fait une chose, mes fichiers de configurations le configure". Ca permet d'avoir un code beaucoup plus simple à lire et à maintenir..
:arrow: serveur J2EE obligatoire : avec Spring, on peut faire une application qui ne necessite pas forcément un serveur J2EE complet pour tourner, et bien fonctionner.

Donc dans l'ensemble, je dirais qu'il y a encore de la marge pour que je me fasse un avis sur la chose plus complet, lorsque j'aurais le temps de le tester et de voir ce que ça donne, mais pour l'instant, je n'ai pas trop l'intention d'abandonner mon bon vieux Spring :)

A+

Moi aussi j'utilise beaucoup Spring dans mes applications, et je dois dire que la première fois que j'ai lu quelques lignes sur JBoss Seam, la première chose qui m'est venue à l'esprit c'est de me dire : "tiens, il s'avance sur le terrain de Spring, ce Seam !!", ce qui m'a amené entre autres à lire ce débat ici : http://www.weiqigao.com/blog/2005/10...titor_now.html

Mais pour tenter de répondre un peu aux critiques formulées par KiLVaiDeN, concernant les annotations, je crois que c'est une vaste question qui ne concerne pas que Seam, et on ne peut y échapper, même Spring s'y met aussi.
Je ne configure plus ma gestion de transactions dans Spring qu'avec @Transactional, et c'est vraiment très pratique, plutôt que d'avoir à tout écrire dans le fichier XML. Plus l'application est de grande taille et plus les fichiers xml deviennent compliqués à gérer et peuvent ralentir le développement.
Les annotations sont un grand bond en avant pour le développeur, mais en même temps elles réduisent la flexibilité apportée par une configuration xml qui permet de modifier le comportement d'un composant au déploiement. Mais heureusement que dans Java EE 5 rien n'empêche d'avoir les deux, la config xml "surpassant" celle de l'annotation.

D'autre part, Seam ne nécessite pas un serveur d'applications, l'installation est possible sur Tomcat, mais n'ayant rien testé encore, je ne sais pas si c'est plus compliqué que pour Spring.

Enfin, pour ce qui est de la couche service, je n'arrive pas à voir où est le problème. Si je devais faire une application Spring intégrant des EJB, j'aurais exactement la même architecture que si je devais utiliser Seam à la place de Spring, et ma couche EJB constituerait bien la couche service. C'est moi qui décide de l'architecture de mon application, et ensuite j'utilise un framework qui me permet d'intégrer plus facilement les différentes couches avec toutes les fonctionnalités qu'elles offrent. Et d'après ce que j'ai compris jusque-là, Seam me permet de le faire autant que Spring.

La seule chose que je reproche à Seam, c'est cette fixation pour l'instant sur JSF comme framework de présentation, alors que moi je préférerais rester à Struts2, par exemple, mais je crois que ça devrait intégrer d'autres framework également à l'avenir, si ce n'est pas déjà fait.

Citation:

---

Enfin, pour ce qui est de la couche service, je n'arrive pas à voir où est le problème.

---

Le problème c'est que si tu veux utiliser Seam Gen pour générer rapidement du code et gagner un peu de temps, tu n'as pas de couche service....

Citation:

---

Si je devais faire une application Spring intégrant des EJB, j'aurais exactement la même architecture que si je devais utiliser Seam à la place de Spring, et ma couche EJB constituerait bien la couche service. C'est moi qui décide de l'architecture de mon application, et ensuite j'utilise un framework qui me permette d'intégrer plus facilement les différentes couches avec toutes les fonctionnalités qu'elles offrent. Et d'après ce que j'ai compris jusque-là, Seam me permet de le faire autant que Spring.

---

Oui je suis entièrement d'accord avec toi à condition de tout coder à la main (ou te recoder ce qu'à produit Seam Gen). Seam Gen peut certainement etre très utile dans les back-office. Mais même dans un back-office, ce serait dommage de se passer de la couche métier

J'utilise maintenant Seam depuis quelques jours, mais je me pose encore des questions quant à l'architecture. Dans le projet que me génére Seam Gen, je place des EJB Stateless et Stateful dans le répertoire "Src/Action" et mes beans Entités dans le repertoire "Src/Model".

Cependant j'ai des classes utilitaires mais je ne sais pas ou les mettre. Biensur je pourrai les mettre dans le répertoire "Src/Action" avec les EJB mais çà ne me semble pas cohérent.

Quelqu'un de confirmé peut-il répondre à ce problème ? Merci à vous :P

• Annotation : permet de définir les défaut que peuvent être surchargés ensuite via des fichiers de configuration
• Seam-gen : permet de faciliter l'écriture d'applications simples (à la Ruby & Rails). Fonctionne à base de templates que vous pouvez prendre en main pour les adapter à vos besoins. Mais vous pouvez aussi ne pas l'utiliser si l'organisation qu'il génère par défaut ne vous aide pas ;)
• Couche service : si vous générez une application CRUD à partir d'un schéma de base de données, vous devriez y retrouver vos petits ;) avec les DAO pour accéder aux entités. La conversation devrait être utilisé.
• EJB3 : vous pouvez utiliser les EJB3 ou de simples POJOs.
• EJB3 bis : pour rappel, les EJB3 n'ont rien à voir avec les EJB2. C'est à mon avis plus simple à utiliser qu'avec une appli hibernate car l'intégration est déjà faite avec les différents services (sécurité, transaction, cluster, ...)
• Stateful : non abordé ici, les coté contextes et stateful qui apporte énormément au modèle

N'hésitez pas à consulter l'excellent livre : http://www.michaelyuan.com/blog/seam...web-framework/

Je me trompe peut être mais la couche "Services" correspond aux EJB3 ? :roll:

D'après la documentation, Seam permettrait de rapprocher la couche applicative (JSF) et la couche services (EJB3). De ce fait, il n'y a plus d'intérêt à partir sur une architecture en 3 couches .. dans ce cas là, autant partir sur Tapestry, Spring et Hibernate.

Seam me semble en revanche très complexe à mettre en place. Je suis partie sur un projet généré par Seam Gen ...

Mon but étant de développer un site de vente en ligne, j'aimerais partir sur une architecture clean.

XmasRock je rebondis sur ce que tu dis ... En effet "seam gen" se base sur des templates mais ce ne sont rien d'autres que des Facelets .... :mrgreen:

Quelqu'un a-t-il un exemple d'architecture de projet Seam mais non généré avec "Seam gen" ? Tous les exemples qui sont livrés avec Seam se basent sur "Seam Gen" ....

Merci à vous tous pour votre soutient...

Citation:

---

Je me trompe peut être mais la couche "Services" correspond aux EJB3 ?

---

EJB3 ou Pojo (regardes l'exemple appelé "hibernate2")

Citation:

---

D'après la documentation, Seam permettrait de rapprocher la couche applicative (JSF) et la couche services (EJB3). De ce fait, il n'y a plus d'intérêt à partir sur une architecture en 3 couches .. dans ce cas là, autant partir sur Tapestry, Spring et Hibernate.

---

Seam c'est plus que ça : http://jboss.com/products/seam/whyseam

Citation:

---

Mon but étant de développer un site de vente en ligne, j'aimerais partir sur une architecture clean.

---

Pour moi Seam est vraiment ce sur quoi je commencerais un nouveau projet. Mais ton choix t'appartient :)

Citation:

---

En effet "seam gen" se base sur des templates mais ce ne sont rien d'autres que des Facelets ....

---

Regardes les sous-répertoires de seam-gen, il y a aussi les templates (squelettes) freemarker servant de base au classes java/fichiers de description ainsi que des tokens qui seront remplacés lors de la copie par ant.

Est-ce que Seam fonctionne uniquement sur JBoss ou il est portable sur n'importe quel serveur J2EE ? Excuse moi si la question est évidente, mais elle est suffisament importante pour savoir si s'engager dans Seam est équivalent à signer un pacte avec JBoss :)

Citation:

---

Quelqu'un a-t-il un exemple d'architecture de projet Seam mais non généré avec "Seam gen" ?

---

J'imagine qu'il te faut lire la doc notamment le chapitre 25 (page 228) : "Configuring Seam and packaging Seam applications"

Citation:

---

Envoyé par KiLVaiDeN

Est-ce que Seam fonctionne uniquement sur JBoss ou il est portable sur n'importe quel serveur J2EE ? Excuse moi si la question est évidente, mais elle est suffisamment importante pour savoir si s'engager dans Seam est équivalent à signer un pacte avec JBoss :)

---

l'exemple hibernate2 est ton ami ;)

Citation:

---

J'imagine qu'il te faut lire la doc notamment le chapitre 25 (page 228) : "Configuring Seam and packaging Seam applications"

---

Merci pour le tuyau !! :lol:

En fait j'ai déjà commencé à développer mon appli Ecommerce en attaquant la partie Authentification.

Ma question première concernait le cryptage d'un mot de passe. Je me demandais à quel niveau je pouvais stocker mes classes. Mais je pense avoir la réponse !!! Je vais me faire un petit fichier jar que je vais intégrer à mon projet !!

As tu déjà développé un petit projet avec Seam ? Moi j'en suis très content .... çà marche très bien et c'est très puissant .... :mouarf:

ce que j'aime, c'est la panoplie de truc prêt à l'emploi et puissants :)

Pour la secu, tu as vu le chapitre 13 ?

Oui j'ai vu le chapitre 13 comme le reste de la doc ... pourquoi j'aurais loupé quelque chose sur le cryptage de chaines ?

non, c'est juste qu'il y a plein de trucs sympas pour la sécu et que ce serait dommage de passer à coté :)

Bon je vais donner mon avis :

Sur la question des couches.

Je pense plutôt que c'est la couche contrôleur qui est absente par défaut (ou bien confondu avec la notion de service), effectivement, comme quelqu'un l'a fait remarquer, les EJB session jouent le rôle de classes de service.
De plus je n'ai pas en tête de framework ou combinaison de framework dont l'utilisation implique de séparation en trois couche. Pour ma part je développe beaucoup d'application Struts(1/2) / Spring / Hibernate, rien ne m'empêche de fusionner les couches mes actions Struts peuvent très bien réaliser les tâches métiers et accéder la couche de persistance. Et puis pour pousser mon raisonnement à l'extrême (de sa stupidité) on peut bien mélanger JSP et couches de persistance.
Enfin, ce genre de remarque s'applique plus à JSF qu'à Seam à mon avis. C'est la liberté fournie pour l'implémentation des backing beans qui laisse le développeur se débrouiller.

En ce qui concerne Seam-gen.

Je crois qu'il ne faut pas essayer de le détourner de son but. De mon point de vue seam-gen est un quickstart pour démarrer une appli web qui fait du CRUD. C'est à mon sens un cas d'utilisation simple avec une valeur ajoutée nulle du développeur. Pour une application aussi simple, pourquoi vouloir à tout prix appliquer le pattern MVC ?

Sur la question de la portabilité du framework.

Là tout n'est pas rose, si beaucoup de choses ont été faites avec la version 2, notamment pour l'utilisation de Tomcat et Hibernate, il y a encore des manques, des choses que l'on peut faire avec JPA et EJB et qui ne marchent pas avec Hibernate. Voici un lien qui décrit quelques configurations qui marchent ou pas
http://www.michaelyuan.com/blog/2007...ation-servers/

Les annotations.

Pour ceux chez qui les annotations provoquent des cauchemar :), sachez qu'il est également possible de déclarer ses composant dans un fichier xml (component.xml). C'est d'ailleurs la seule manière de créer plusieurs composants de même type avec des noms et des scope différents, cela permet également d'impacter sur les composants prédéfinis.

Spring et Seam.

Je ne pense pas que Spring et Seam s'excluent mutuellement. Je pense que Spring est d'une très (très (très)) grande richesse et que Seam apporte d'autres moyens d'intégration de certains framework (drools, jBPM, etc ...) ainsi que la notion de Statefull. Bien sûr, les deux framework proposent certains outils concurrents (la gestion des transactions pour ne citer que cela), mais ils s'enrichissent mutuellement. Exemple 1 : avec Hibernate et Spring il est (me semble-t-il) plus simple de récupérer le transaction manager du serveur d'applis J2EE qu'avec Seam. Exemple 2 : Seam permet d'encapsuler les bean Spring pour leur donner la notion de Statefull.

Pour finir je reprends la liste des avantages inconvénients énoncée précédemment.

Citation:

---

Avantages :

• rapidité de développement. Quand on voit la taille des codes sources donnés en exemple et les fonctionnalités qu'ils implémentent, on ne peut qu'admettre que ça a l'air plutôt facile à appréhender.

• configuration via les annotations : je mettrais ce point aussi dans les inconvénients, mais il est vrai que certaines personnes peuvent aussi apprécier d'avoir à la fois la configuration et la logique dans un même listing. De plus ça peut aider pour le refactoring.

• intégration avec les standards J2EE : Seam parait forcer l'utilisation des standards, ce qui dans l'ensemble est une bonne chose pour le futur, et pour la portabilité. jpa

• outils de développement : les outils mis en place paraissent simples et efficaces dans la génération de code.

Inconvénients :

• où est passée la couche service ? peut-être qu'il faudra attendre un peu pour qu'avec le retour sur l'expérience on voit de nouveaux patterns afin de bien gérer ce type de projet avec une meilleure séparation des couches.

• la configuration via les annotations : je cite ceci dans les inconvénients aussi, car j'adore le coté "mon Pojo fait une chose, mes fichiers de configuration le configure". Ça permet d'avoir un code beaucoup plus simple à lire et à maintenir..

• serveur J2EE obligatoire : avec Spring, on peut faire une application qui ne nécessite pas forcément un serveur J2EE complet pour tourner, et bien fonctionner.

---

Malheureusement pour la rapidité de développement, je mettrai un bémol car le ticket d'entrée dans le framework me semble assez élevé par contre c'est clair qu'une fois le framework bien connu c'est certainement l'un de ceux qui permettent de mettre en place une appli entreprise le plus rapidement.
Pour les annotations, comme je l'ai fait remarquer, ce n'est pas la seule manière de faire. Je pense que sur ce point les querelles de clocher ne sont pas les bienvenues. Certaines choses seront plus élégantes avec des annotations, d'autres seront moins complexes avec des fichiers de déclaration.
Pour le côté J2EE de la chose, ça bouge beaucoup. Je n'ai pas spécialement de problème à faire tourner des applis avec Tomcat et Hibernate (surtout avec Seam v2). Il manque quelques bricoles, mais cela va changer dans les prochaines versions.

David

Citation:

---

Envoyé par Uncle Dave

Spring et seam.

Je ne pense pas que Spring et Seam s'excluent mutuellement. Je pense que Spring est d'une très (très (très)) grande richesses et que Seam apporte d'autres moyens d'intégration de certains framework (drools, jBPM, etc ...) ainsi que la notion de Statefull. Bien sûr, les deux framework proposent certains outils concurrents (la gestion des transactions pour ne citer que cela), mais ils s'enrichissent mutuellement. Exemple 1 : avec Hibernate et Spring il est (me semble-t-il) plus simple de récupérer le transaction manager du serveur d'applis J2EE qu'avec Seam. Exemple 2 : Seam permet d'encapsuler les bean Spring pour leur donner la notion de Statefull.

---

Bonjour,
Pourrais-tu développer un peu ta pensée sur la gestion des transactions, et en quoi Spring et Seam proposent des solutions différentes ? En quoi par exemple serait-il moins simple de récupérer le transaction manager avec Seam ? Seam étant conçu et développé par la même équipe que celle de Hibernate, étant en plus mieux intégré à EJB3, il me semble que cet aspect de transactions ne devrait pas être un souci, je me trompe ?

Pour ce qui est de l'accès au framework (le "learning curve"), je crois que les deux frameworks, Spring et Seam, sont équivalents dans la mesure où les deux se proposent d'être fondamentalement des frameworks d'intégration, ce qui nécessite d'abord une bonne maîtrise des autres frameworks qui seront intégrés. Dans le cas de Seam, pour réaliser une application sérieuse il faudrait d'abord bien connaître au moins JSF, EJB3, JPA (Hibernate/TopLink), jBPM..., ce qui évidemment représente beaucoup pour commencer.
De même pour Spring, il faudrait déjà connaître au moins Hibernate (ou JPA), peut-être aussi EJB 3, AspectJ (AOP), et au moins un framework web (Struts1/2, SpringMVC, Tapestry,...), ce qui fait beaucoup aussi quand on débute.
Mais pour ce qui est de Spring et Seam en tant que frameworks eux-mêmes, je crois qu'ils ne sont pas très difficiles à apprendre, dans la manière dont ils facilitent l'intégration et surtout les plus qu'ils apportent au développeur en facilitant encore plus le développement d'applications d'architecture complexe, et moins complexe aussi d'ailleurs.

Citation:

---

Pourrais-tu développer un peu ta pensée sur la gestion des transactions

---

Je ne parle pas du cas EJB mais du cas hibernate pur, dans le cas de Spring il le fait pour toi avec une ligne du genre.

Code:

---

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager" />

---

Ce n'est pas à proprement parler un souci c'était simplement un exemple pour illustrer les différences avec Spring ce n'est en rien structurant, c'est simplement l'exemple qui me viens.

Bien sur c'est un exemple biaisé puisqu'il il ne correspond pas à un cas d'utilisation JEE mais JSE. Cependant cela illustre bien que dans certain cas il peut être interessant de s'appuyer également sur Spring.

(dans le cas JEE je pense que seam pourrai même être mieux intégré mais je ne suis pas cappable d'exprimer un avis fiable sur la question)

Pour l'aspect learning curve, je suis d'accord avec toi, je ne songeai cependant pas à comparer les deux qui, je le répète me semble avoir une intersection de fonctionnalité non-nulle mais par ailleur offrir des possibilité différentes.
Ceci dit au delà de leurs principes architecturaux qui sans être simplistes sont relativement facile d'accès, ces frameworks trouvent leur principal intérêt dans leur capacité à intégrer d'autres tiers. Par conséquent on en bénéficie réellement qu'en ayant une vision suffisament large du vaste écosystème dans lequel elles s'intégrent.

Citation:

---

Sur la question des couches.

Je pense plutôt que c'est la couche controlleur qui est absente par défaut (ou bien confondu avec la notion de service), effectivement, comme quelqu'un la fait remarquer, les EJB session jouent le rôle de classes de service.

---

C'est exactement le reproche que je ferai. Confondre la couche controleur et la couche service c'est caca :evilred:

Citation:

---

De plus je n'ai pas en tête de framework ou combinaison de framework dont l'utilisation implique de séparation en trois couche. Pour ma part je dévelloppe beaucoup d'application Struts(1/2)/Spring/hibernate, rien ne m'empêche de fusionner les couches mes actions Struts peuvent très bien réaliser les tâches métiers et accéder la couche de persistence. Et puis pour pousser mon raisonnement à l'extreme (de sa stupidité) on peut bien mélanger JSP et couches de persistence.

---

Ba ca c'est pas bien non plus : mettre des fonctionnalités métiers dans la couche Action...Parce que comme tu le dit, pour "pousser à l'extreme", on revient aux développements d'y a 5 ans, style "asp", tout dans une page !!! Et on se retrouve avec des applis in-maintenable :(

Citation:

---

Enfin, ce genre de remarque s'applique plus à JSF qu'à Seam à mon avis. C'est la liberté fournit pour l'implémentation des backing beans qui laisse le devellopeur se débrouiller.

---

C'est la où le bas blesse, non ? Si le framework ne fournit pas les bases minimumes, on se retrouve avec une appli non structurée et donc difficile à faire évoluer.

Citation:

---

En ce qui concerne Seam-gen.

Je crois qu'il ne faut pas essayer de le détourner de son but. De mon point de
vue seam-gen est un quickstart pour démarrer une appli web qui fait du CRUD. C'est à mon sens un cas d'utilisation simple avec une valeur ajoutée nulle du développeur. Pour une application aussi simple, pourquoi vouloir à tout prix appliquer le pattern MVC ?

---

Je pense qu'avec seam-gen, tu peux générer tres rapidement les structures de ton appli. Qu'elle soit petite ou importante, peu importe la taille de ton appli, le gain de temps est appréciable.
Alors pourquoi le faire, si c'est pour le faire mal ? Peu importe la taille de l'appli, personne n'aurait l'idée de constuire une appli de nos jours sans utiliser le pattern MVC ni la séparation en 3 couches.

Non, vraiment, il me semble que Seam est un bon produit, mais les exemples dans les tutoriaux ainsi que seam-gen sont à revoir....

Bonjour.

Citation:

---

Envoyé par Uncle Dave

Enfin, ce genre de remarque s'applique plus à JSF qu'à Seam à mon avis. C'est la liberté fournit pour l'implémentation des backing beans qui laisse le devellopeur se débrouiller.

---

Citation:

---

Envoyé par ericw78

C'est la où le bas blesse, non ? Si le framework ne fournit pas les bases minimumes, on se retrouve avec une appli non structurée et donc difficile à faire évoluer.

---

Oh la là ! Qui est ce qui dit du mal de mon JSF chéri ? La, je me dois de réagir !
Plus sérieusement, ça n'a strictement rien à voir avec JSF (ni tout autre framework Web Java d'ailleurs)! On ne peut pas empêcher un programmeur de ne pas respecter la MVC que ce soit dans JSF ou Struts: Il est parfaitement possible de faire du code métier dans les actions Struts aussi ! Ce n'est pas parceque les managed beans de JSF sont flexibles (POJOs ordinaires, au lieu de suivre un plan rigide (à la Struts 1.x) ) qu'il encourage à casser le MVC !

:arrow: A moins bien sur qu'un jour on puisse réaliser des outils intelligents et proactifs qui instrospectent le code des controleurs en les emêchant de toucher à la base ou de faure de la logique métier, le MVC restera toujours à la seule et unique responsabilité des programmeurs !

Un outil n'est qu'un outil. C'est ton expertise qui te permet d'avoir une valeur ajoutée en tirant profit du meilleurs de l'outil pour adresser ta problématique courante.

Citation:

---

Oh la là ! Qui est ce qui dit du mal de mon JSF chéri ? La, je me dois de réagir !
Plus sérieusement, ça n'a strictement rien à voir avec JSF (ni tout autre framework Web Java d'ailleurs)! On ne peut pas empêcher un programmeur de ne pas respecter la MVC que ce soit dans JSF ou Struts: Il est parfaitement possible de faire du code métier dans les actions Struts aussi ! Ce n'est pas parceque les managed beans de JSF sont flexibles (POJOs ordinaires, au lieu de suivre un plan rigide (à la Struts 1.x) ) qu'il encourage à casser le MVC !

---

Non, mon intention n'est pas de juger ni JSF ni Struts ni tel autre framework.

Citation:

---

A moins bien sur qu'un jour on puisse réaliser des outils intelligents et proactifs qui instrospectent le code des controleurs en les emêchant de toucher à la base ou de faure de la logique métier, le MVC restera toujours à la seule et unique responsabilité des programmeurs !

---

:king: Je suis à 100% d'acccord avec toi c'est pourquoi j'insiste sur le fait de disposer de "bons tutoriaux" qui pousseront le plus possible le développeur vers les "bonnes méthodes"

Citation:

---

Citation:

---

Citation:
Sur la question des couches.

Je pense plutôt que c'est la couche controlleur qui est absente par défaut (ou bien confondu avec la notion de service), effectivement, comme quelqu'un la fait remarquer, les EJB session jouent le rôle de classes de service.

---

C'est exactement le reproche que je ferai. Confondre la couche controleur et la couche service c'est caca

---

mettre ses services dans les ejb session n'est pas une erreur de conception (au contraire), utiliser les ejb session comme contrôlleur par contre peut être considéré comme tel (separation of concern).

Personnellement pour moi, l'important est le respect de la separation of concern, après l'utilisation de tel ou tel pattern (MVC2 en l'occurence) me semble secondaire.

Citation:

---

Je suis à 100% d'acccord avec toi c'est pourquoi j'insiste sur le fait de disposer de "bons tutoriaux" qui pousseront le plus possible le développeur vers les "bonnes méthodes"

---

Là OK, je vais essayer de trouver un contre exemple, mais c'est pas gagné :aie:

OK après quelques lecture, je trouve que l'exemple du blog livré avec seam est plutôt orienté MVC, la partie contrôleur est entièrement réalisée avec le fichier de configuration de la navigation.

Euh, vous me pardonnerez mon impertinence, mais la fameuse couche contrôleur que vous réclamez n'est-elle pas Seam itself ?

Blague à part, avez-vous de bonnes sources d'infos, conseils, tutos... pour maîtriser les conversations en profondeur ? Je trouve ça puissant sur le papier, mais pas trivial du tout sur le terrain.
En particulier, pour faire de la réutilisation de "use case" : je suis dans une conversation, je débranche temporairement vers une "sous conversation", et quand cette dernière est finie je reviens automatiquement vers la conversation principale.
Je n'ai pas trouvé de moyen autrement qu'en spécifiant un outcome prédéfini, ce qui casse la notion de "use case réutilisable".

J'ai eu l'occasion d'essayer ce Frameworks et voici mon point de vue.

N'hésitez pas à me corriger, si je dis des bêtises ... :roll:

Les exemples fournis montrent souvent des affichages avec des DataTables. Les checkboxs sont utilisés dans les formulaires et sont souvent mappées avec des propriétés booléennes des objets. Jusque là tout va bien !

Mais, si l'on souhaite effectuer une sélection d'objet avec des checkboxs, on se retrouve avec une "Map<Objet,Boolean> objetsSelectionnes" dans le backing bean qui joue aussi le rôle de Service. Le but de cette Map est d'extraire la liste des objets sélectionnés afin d'y effectuer des actions. Elle n'est utilisée que pour la sélection qui se fait à partir de la Vue (JSF). Au niveau métier, je n'ai besoin que d'une liste d'objet.

En fait, je trouve que la couche Service/Métier qui correspond pour moi aux EJB Session, se retrouve "polluée" par des fonctionnalités qui sont spécifiques à la Vue. 8O

Ai-je raison ?
Y a-t-il un moyen de pallier à cela ?

Dans l'ensemble, Seam reste assez sympa à utiliser. :D

Salut,

pour ton histoire de checkbox, je passe mon tour, par contre pour le côté pollution, on peut tout à fait faire cohabiter un jar "pojo" d'un coté et un jar ejb de l'autre. Ca se déploie très bien dans jboss, faut juste que ton jar ait un fichier seam.properties dans son META-INF. Comme ça tu code chaque chose à sa place.

Citation:

---

Euh, vous me pardonnerez mon impertinence, mais la fameuse couche contrôleur que vous réclamez n'est-elle pas Seam itself ?

---

:P oui, on aurait peut-être dû commencer par là

Citation:

---

Blague à part, avez-vous de bonnes sources d'infos, conseils, tutos... pour maîtriser les conversations en profondeur ? Je trouve ça puissant sur le papier, mais pas trivial du tout sur le terrain.

---

la doc est déjà pas mal faite, moi je me suis pas mal appuyé sur le bouquin de Michael Yuan

Citation:

---

En particulier, pour faire de la réutilisation de "use case" : je suis dans une conversation, je débranche temporairement vers une "sous conversation", et quand cette dernière est finie je reviens automatiquement vers la conversation principale.
Je n'ai pas trouvé de moyen autrement qu'en spécifiant un outcome prédéfini, ce qui casse la notion de "use case réutilisable".

---

Hum, arrête-moi si je me trompe, mais je pense que tu mélanges conversation et navigation.
Quand tu termines une conversation imbriquée (<end-conversation/> ou @end), tu te retrouves automatiquement dans le contexte de la conversation parente, mais cela n'est pas automatiquement corrélé à la navigation.
Une des manières de corréler plus fortement conversation et navigation est d'utiliser un pageflow pdl au lieu de la navigation normale
http://docs.jboss.com/seam/2.0.2.GA/...l_single/#jbpm

Mais je ne pense pas que cela résolve exactement ton problème. Ce qui serait envisageable serait de capter l'id de la vue précédent la création de la conversation et de l'utiliser comme outcome de ta méthode de fin de conversation, ce qui te renverrait à la dernière vue de la conversation parente si aucune règle plus forte n'est décrit dans le page.xml.

Dav

Je ne comprends pas bien les problématiques débattues jusqu'ici :

1) Annotations vs fichiers de configuration.
- Est-ce que les deux notions s'excluent ?
- Je pense que la spécification EJB3 permet d'utiliser les deux, le fichier de config ayant la priorité sur les annotations quand les deux existent
- Est ce que Seam ne permet pas de gérer les deux ? Dans ce cas, c'est le monde idéal, on utilise les annotations pendant la phase de développement, puis les fichiers de configuration pendant la phase de maintenance.

2) La présence d'une couche service/contrôleur.
- La division en couche n'est-elle pas du ressort du concepteur ?
- Où est le problème si on utilise une session bean S1 comme contrôleur et une autre S2 comme fournisseur de service ? Les sessions bean devraient être vus tout simplement comme des objets serveur manageable par un conteneur JEE. C'est au concepteur de leur assigner un rôle dans son appli.

Citation:

---

Envoyé par kisitomomotene

Je ne comprends pas bien les problématiques débattues jusqu'ici :

1) Annotations vs fichiers de configuration.
- Est-ce que les deux notions s'excluent ?
- Je pense que la spécification EJB3 permet d'utiliser les deux, le fichier de config ayant la priorité sur les annotations quand les deux existent
- Est ce que Seam ne permet pas de gérer les deux ? Dans ce cas, c'est le monde idéal, on utilise les annotations pendant la phase de développement, puis les fichiers de configuration pendant la phase de maintenance.

2) La présence d'une couche service/contrôleur.
- La division en couche n'est-elle pas du ressort du concepteur ?
- Où est le problème si on utilise une session bean S1 comme contrôleur et une autre S2 comme fournisseur de service ? Les sessions bean devraient être vus tout simplement comme des objets serveur manageable par un conteneur JEE. C'est au concepteur de leur assigner un rôle dans son appli.

---

Seam permet bien entendu de gérer les deux. Il intègre EJB3, il ne les sur-couche pas. La seule pseudo sur-couche aux EJB ce sont les composants Seam qui sont transactionnels.

Entièrement d'accord pour le point numéro 2, c'est au concepteur d'architecturer le projet.

Pour revenir à ce qui a été dit sur le Seam-gen, les concepteurs de Seam le disent eux-même, il n'a pas pour but de créer des gros projets d'entreprise, mais de faciliter la développement d'applis CRUD, qui globalement reviennent toujours à faire la même chose, si ce n'est de changer le nom et deux ou trois associations entre objets. J'exagère un peu mais peut-être pas tant que ça ?
Je l'ai aussi utilisé pour démarrer des projets et faire des maquettes.

Ca fait grosso modo 6 mois que je bosse avec Seam, Spring m'as toujours rebuté car pour moi il y a beaucoup trop de configuration XML à faire et le démarrage d'un projet est complètement laborieux. Je reconnais ses qualités mais là dessus je ne démords pas.

Les annotations de Seam permettent de voir tout clairement au niveau de l'objet. En plus la gestion des cycles de vie et des contexte est d'une simplicité déconcertante une fois qu'on a pas mal exploré le framework

Mais pour revenir à un des posts que j'ai lu, il est clair que Seam demande pas mal de formations avant de l'utiliser correctement, et qu'au début on peut faire beaucoup de grosses bêtises sans le vouloir, en essayant d'utiliser à tort les facilités du framework (j'en ai fait pas mal au début).

Maintenant pour l'architecture, personnellement je divise toujours mes projets en 3 sous-projets :

• Projet entities qui contient les EJB Entity
• Projet services qui contient les services, que ce soit des services de type EJB Session, Message, ou les composants Seam.
• Projet war, qui est la webapp et qui contient la partie JSF et les quelques fichiers de conf XML que Seam conserve (faces-config.xml, web.xml, components.xml, pages.xml ..) dans le WEB-INF.

Et on peut continuer sur ce modèle pour architecturer encore plus.

Le tout buildé avec Maven pour arriver soit à un seul ear contenant les 3 projets, soit à 2 ear (un pour le front et un pour le back office) quand c'est une appli distribuée. Ca demande un peu de travail sur Maven mais soit dit en passant, l'association Seam/Maven permet vraiment une grande flexibilité.

Pour la maitrise de la conversation, j'ai qu'un seul conseil c'est la pratique, puis c'est déjà commencer par essayer de mettre le plus d'objets à conservation d'état possible dans cette dernière.
Beaucoup d'objets qu'on va mettre naturellement et par automatisme en session, auraient tout à fait leur place en conversation. Cela demande un peu plus de réflexion et peut-être de travail (gestion des long running conversation) mais cela permet d'optimiser pas mal la mémoire et le cycle de vie des objets.

@ Mikrob

dans le cas d'un projet distribué, tu mets le projet entities et le projet service dans un ear et projet war dans l'autre?

ça dépend de la distribution que je dois faire.