Y a-t-il des inconvénients à la couture?

Il me semble naturel et utiliser des annotations facilite la vie. Je ne peux même pas imaginer travailler avec Getattribute / GetParameter Cadre. Un inconvénient est que Camen-Gen ne fonctionne pas avec Maven (mais la couture 3 sera mavenée). Je pense que la couture vous rend concentrant sur ce que vous voulez atteindre et avec d'autres cadres que vous devez penser à le faire. Avez-vous déjà essayé de faire Ajax avec JavaScript / Prototype / JQuery? C'est vraiment douloureux par rapport au bouton de couture Ajax avec l'appel de la méthode et quoi de rédaction. JavaScript n'est vraiment pas nécessaire du tout avec une couture et des visages riches. Pour moi, c'est le meilleur cadre que j'ai utilisé.

L'avantage de tout cadre comme une couture ou des greils est qu'il s'agit d'un niveau d'abstraction plus élevé. Il s'occupe des détails sous-jacents pour vous et, s'il est conçu et écrit bien, facilite les choses.

L'inconvénient de tout cadre comme la couture ou les grails est qu'il cache beaucoup de détails de votre part. Si vous n'apprenez jamais ce qui se passe sous vous, vous pouvez vous retrouver dans un monde de problèmes si vous êtes coincé et que vous ne savez rien sur le code généré pour vous.

Un autre inconvénient est que les hypothèses qu'ils construisent dans le modèle ne sont peut-être pas toujours ce que vous voulez. Mais les changer signifie briser le chemin qu'ils ont défini pour vous, ce qui n'est pas facile.

Mon conseil serait d'utiliser le cadre et d'apprécier les avantages qu'il apporte, mais ne les utilisez pas comme une excuse pour arrêter d'apprendre ce qui se passe en dessous. Soyez la personne qui pourrait écrire le tout à la main, sans le cadre, mais choisit de l'utiliser pour l'effet de levier qu'il fournit.

Ce n'est pas correct de dire que la "couture est la prochaine étape de JSF". La couture n'a pas à utiliser JSF comme couche de vue. Il peut également utiliser Wicket ou GWT .

Cependant, lorsqu'il est utilisé avec JSF, il fait un excellent travail de simplifier. Vous avez moins de configuration XML que Standard JSF et j'oublie souvent que JSF n'a pas de choses comme un contexte de conversation ou des appels de méthode paramétrés dans EL. EG: P>

<h:commandButton action="#{myBean.sayHello('damo')}" value="hello"/>

• trop de dépendance à l'adresse http (qui s: bouton / lien code> ne résout pas toujours) li>
• beaucoup de javascript li>
• Appels excessives à Getters / Setters Li>
• Nasty HTML HTML; etc li> ul>

  Il y a plus que suffisamment de pages détaillant les lacunes de JSF ailleurs (notez que ce ne sont pas des critiques de couture - plutôt de JSF1.x et de nombreux sont résolus dans JSF2.0) P>

  Je ne crois pas que la couture est la "prochaine étape «Pour JSF, mais les facelets sont cruciaux si vous envisagez d'utiliser JSF1.x en ce moment. P>

  Je pense que JSF2 .0 et Webbeans sont la prochaine étape. p> p>

J'aime JSF et j'ai évalué la couture il n'y a pas longtemps. JSF est un cadre d'interface utilisateur Web, tandis que la soudure est un cadre d'application Web plus général, qui intègre non seulement JSF, des contextes de conversation, un flux de travail (JBPM) et une persistance d'objet (de préférence EJB3). J'ai d'abord été attiré par la couture par l'échafaudage automatiquement généré automatiquement, mais je n'ai jamais eu la possibilité de travailler avec mon modèle de données d'entreprise. Depuis lors, je suis plus intéressé par le cadre de printemps et le Spring JSF. Il me fait appel comme étant plus modulaire et si vous utilisez Ibatis, il n'a besoin que d'un conteneur de servlet comme Tomcat, pas un conteneur Java EE comme JBoss. Le printemps a été autour plus longtemps et a de plus en plus d'esprits.

Les glaces sont également superbes avec JSF et FACELETS, cela fonctionne parfaitement avec ou sans cadre d'application comme une couture ni un ressort.

Je l'ai utilisé Seam dans un projet en cours avec largish Icefaces. Seam est certainement beaucoup mieux que d'utiliser JSF simple (voir le lien affiché par Damo quelques réponses ci-dessus).

Cependant, quelques-unes des questions que je me souviens:

• les tests unitaires: obtenir SeamTest fonctionne correctement en particulier dans une construction d'intégration continue était difficile, recherche sur le Web pour « SeamTest questions ». Voir aussi ceci: Quelqu'un at-il exécuté avec succès tests d'intégration avec Jboss intégré, Seam et Maven?
• De multiples façons pour les développeurs de faire des choses et pas trop de meilleures pratiques documentées. Donc, vous devez passer du temps et comprendre ce qui est le mieux pour votre équipe de projet. Par exemple, la mise en œuvre des formes, voici les balises potentiels (notez que certains d'entre eux se chevauchent):

  Facelets

  JSTL

  JSF

  ICEFaces

  JSF

  Seam

  • performance est suspect, surtout avec Icefaces, Accélérez votre Data-Driven JSF / Seam application par deux ordres de grandeur - Partie 1
  • depuis Seam 3 est imminente, et censé utiliser 2 nouvelles spécifications (JSF 2 et WebBeans) qui laisse des questions sur ce qui se passe à des projets sur Seam 2 et combien de temps il faudra pour que les choses se stables
  • courbe d'apprentissage. Les essais de IMHO d'en faire trop, vous donnez enrubanneuse sur des choses comme iText, Quartz, JExcel, jBPM, etc. Et l'intégration Seam avec les cadres de tiers est expectedly un pas derrière les dernières versions. Par exemple, nous avons dû intégrer jBPM directement parce que nous avions besoin d'une des dernières fonctionnalités.
  • peut-être à cause du manque de requêtes de critères dans JPA 1.X, la façon dont vous implémentez les écrans de recherche dynamiques (où remplissages utilisateur dans un grand nombre d'options de filtrage et vous devez générer HQL dynamique) se sentait très en élégance, et ce est l'utilisation du recommandé « cadre Seam application » classe EntityQuery, voir le lien ci-dessous pour un exemple simple, mais vous pouvez avoir une idée de ce qu'il faut attendre des critères de filtrage complexes, la manipulation des valeurs nulles, l'ordre par et tous: How puis-je commander une requête EntityQuery dans une application de couture

Seam, en tant que cadre d'intégration, va vraiment montrer son utilité lorsqu'il est associé à d'autres cadres que vous souhaitez utiliser.

Si vous allez utiliser EJB et JSF déjà, SEAM est le tueur.

Si vous allez utiliser JSF (plus l'un de ses outils connexes, comme Icefaces ou RichFaces) SEAM POJO peut simplifier votre configuration beaucoup ainsi que vous donner accès aux états du cycle de vie qui fournit la couture (la conversation , etc.)

Si vous utilisez EJB avec Wicket ou GWT, Seam pourrait être en mesure de vous sauver une configuration aussi bien, cependant, je n'ai pas personnellement utilisé dans cette configuration.

Comme on l'a dit, les inconvénients de Seam sont inhérents à tout cadre d'abstraction: Il se cache les détails de votre part. Si elle commence à fuir, vous êtes en difficulté. Je n'ai pas eu sur moi encore, mais je fuite aussi passé le temps de me donner une bonne compréhension de base de la façon dont cela fonctionne. Comment l'EL fonctionne avec les annotations Seam et autres.

Si oui ou non vous allez trouver la couture utile dépend des cadres que vous allez l'utiliser avec. Seam a certainement sa tache douce mais cet endroit est de plus en plus. Seam est certainement pas un projet mort. :)

Si vous mettez un enregistreur sur votre composant de couture (par exemple, des résultats), vous verrez que cette couture appelle la même méthode plusieurs fois. C'est le seul train ennuyeux sur la couture. Mais couture définitivement "corrigé" JSF qui est jolie en panne de lui-même. Permet de voir JSF2. Peu importe ces problèmes, je suis très heureux d'utiliser la couture.

Vous pouvez toujours utiliser l'annotation usine pour éviter les appels sur la même méthode de plus et plus. L'usine permet de mettre à jour le composant.