+ Répondre à la discussion
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 36
  1. #1
    Membre expérimenté

    Inscrit en
    avril 2005
    Messages
    317
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 317
    Points : 514
    Points
    514

    Par défaut 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
    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

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

  2. #2
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 673
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 673
    Points : 7 849
    Points
    7 849

    Par défaut

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

    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 ?

  3. #3
    Invité de passage
    Inscrit en
    novembre 2007
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 1
    Points : 1
    Points
    1

    Par défaut

    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.

  4. #4
    Membre expérimenté

    Inscrit en
    avril 2005
    Messages
    317
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 317
    Points : 514
    Points
    514

    Par défaut

    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

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    novembre 2007
    Messages
    50
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : novembre 2007
    Messages : 50
    Points : 20
    Points
    20

    Par défaut Architecture SEAM

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

    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 ??

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    365
    Détails du profil
    Informations personnelles :
    Localisation : Maroc

    Informations forums :
    Inscription : janvier 2006
    Messages : 365
    Points : 491
    Points
    491

    Par défaut

    Citation Envoyé par anicaise Voir le message
    Seam s'appuie en effet sur une architecture 2 tiers. Exit donc la couche services !
    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.

  7. #7
    Expert Confirmé Avatar de KiLVaiDeN
    Inscrit en
    octobre 2003
    Messages
    2 725
    Détails du profil
    Informations forums :
    Inscription : octobre 2003
    Messages : 2 725
    Points : 3 045
    Points
    3 045

    Par défaut

    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 :
    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 developpement : 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'experience 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 configurations le configure". Ca permet d'avoir un code beaucoup plus simple à lire et à maintenir..
    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+
    K

  8. #8
    Membre éprouvé
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    365
    Détails du profil
    Informations personnelles :
    Localisation : Maroc

    Informations forums :
    Inscription : janvier 2006
    Messages : 365
    Points : 491
    Points
    491

    Par défaut

    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.

  9. #9
    Membre expérimenté

    Inscrit en
    avril 2005
    Messages
    317
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 317
    Points : 514
    Points
    514

    Par défaut

    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....

    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

  10. #10
    Membre à l'essai
    Profil pro
    Inscrit en
    novembre 2007
    Messages
    50
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : novembre 2007
    Messages : 50
    Points : 20
    Points
    20

    Par défaut

    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

  11. #11
    Membre émérite Avatar de XmasRock
    Inscrit en
    janvier 2007
    Messages
    729
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 729
    Points : 811
    Points
    811

    Par défaut

    • 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/

  12. #12
    Membre à l'essai
    Profil pro
    Inscrit en
    novembre 2007
    Messages
    50
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : novembre 2007
    Messages : 50
    Points : 20
    Points
    20

    Par défaut

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

    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 ....

    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...

  13. #13
    Membre émérite Avatar de XmasRock
    Inscrit en
    janvier 2007
    Messages
    729
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 729
    Points : 811
    Points
    811

    Par défaut

    Je me trompe peut être mais la couche "Services" correspond aux EJB3 ?
    EJB3 ou Pojo (regardes l'exemple appelé "hibernate2")

    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

    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

    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.

  14. #14
    Expert Confirmé Avatar de KiLVaiDeN
    Inscrit en
    octobre 2003
    Messages
    2 725
    Détails du profil
    Informations forums :
    Inscription : octobre 2003
    Messages : 2 725
    Points : 3 045
    Points
    3 045

    Par défaut

    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
    K

  15. #15
    Membre émérite Avatar de XmasRock
    Inscrit en
    janvier 2007
    Messages
    729
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 729
    Points : 811
    Points
    811

    Par défaut

    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 Voir le message
    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

  16. #16
    Membre à l'essai
    Profil pro
    Inscrit en
    novembre 2007
    Messages
    50
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : novembre 2007
    Messages : 50
    Points : 20
    Points
    20

    Par défaut

    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 !!

    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 ....

  17. #17
    Membre émérite Avatar de XmasRock
    Inscrit en
    janvier 2007
    Messages
    729
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 729
    Points : 811
    Points
    811

    Par défaut

    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 ?

  18. #18
    Membre à l'essai
    Profil pro
    Inscrit en
    novembre 2007
    Messages
    50
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : novembre 2007
    Messages : 50
    Points : 20
    Points
    20

    Par défaut

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

  19. #19
    Membre émérite Avatar de XmasRock
    Inscrit en
    janvier 2007
    Messages
    729
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 729
    Points : 811
    Points
    811

    Par défaut

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

  20. #20
    Membre à l'essai
    Inscrit en
    juin 2007
    Messages
    19
    Détails du profil
    Informations personnelles :
    Âge : 33

    Informations forums :
    Inscription : juin 2007
    Messages : 19
    Points : 22
    Points
    22

    Par défaut

    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.
    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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •