web-dev-qa-db-fra.com

Structure de haricot de soutien JSF (meilleures pratiques)

J'espère que dans cet article, je pourrai obtenir l'opinion des gens sur les meilleures pratiques en matière d'interface entre les pages JSF et les beans de sauvegarde.

Une chose sur laquelle je ne peux jamais m'installer est la structure de mes haricots. De plus, je n'ai jamais trouvé un bon article sur le sujet.

Quelles propriétés appartiennent à quels haricots? Quand est-il approprié d'ajouter plus de propriétés à un bean donné plutôt que de créer un nouveau bean et d'y ajouter les propriétés? Pour les applications simples, est-il judicieux d’avoir un seul haricot de sauvegarde pour toute la page, compte tenu de la complexité liée à l’injection d’un haricot dans un autre? Le bean de support doit-il contenir une logique métier réelle ou doit-il contenir strictement des données?

N'hésitez pas à répondre à ces questions et à d’autres éventuelles.

En ce qui concerne la réduction du couplage entre la page JSF et le bean de support, je ne permets jamais à la page JSF d’accéder aux propriétés des propriétés du bean de support. Par exemple, je n'autorise jamais quelque chose comme:

<h:outputText value="#{myBean.anObject.anObjectProperty}" />

J'ai toujours besoin de quelque chose comme:

<h:outputText value="#{myBean.theObjectProperty}" />

avec une valeur de haricot de support de:

public String getTheObjectProperty()
{
    return anObject.getAnObjectProperty();
}

Lorsque je boucle sur une collection, j'utilise une classe wrapper pour éviter de faire un zoom avant sur un objet d'une table de données, par exemple.

En général, cette approche me semble "juste". Cela évite tout couplage entre la vue et les données. Corrigez-moi si j'ai tort, s'il-vous plait.

javajsf
116
Zack Marrapese

Vous voudrez peut-être vérifier ceci: faire des distinctions entre différents types de beans gérés par JSF .

Voici une description des différents types de haricots, tels que définis dans l'article ci-dessus de Neil Griffin:

  • Model Managed-Bean : Portée normalement de la session. Ce type de bean géré participe à la préoccupation "Modèle" de le modèle de conception MVC. Lorsque vous voyez le mot "modèle", pensez à DATA. Un modèle-bean JSF doit être un POJO qui suit le modèle de conception JavaBean avec des propriétés d'encapsulation des getters/setters. Le cas d'utilisation le plus courant d'un bean modèle consiste à être une entité de base de données ou à simplement représenter un ensemble de lignes à partir du jeu de résultats d'une requête de base de données.
  • Sauvegarde du bean géré : Normalement, demander la portée. Ce type de bean géré participe à la préoccupation "Voir" de le modèle de conception MVC. Le but d'un bean de support est de prendre en charge la logique de l'interface utilisateur et a une relation 1: 1 avec une vue JSF ou une forme JSF dans une composition Facelet. Bien qu'il comporte généralement des propriétés de style JavaBean avec des getters/setters associés, il s'agit des propriétés de la vue, et non du modèle de données de l'application sous-jacente. Les beans de support JSF peuvent également avoir des méthodes JSF actionListener et valueChangeListener.
  • Controller Managed-Bean : Normalement, demander la portée. Ce type de bean géré participe à la préoccupation "Contrôleur" de le modèle de conception MVC. Le rôle d'un bean contrôleur est d'exécuter une sorte de logique métier et de renvoyer un résultat de navigation au gestionnaire de navigation JSF. Les contrôleurs-beans JSF ont généralement des méthodes d'action JSF (et non des méthodes actionListener).
  • Support Managed-Bean : Normalement session ou champ d'application. Ce type de bean "prend en charge" une ou plusieurs vues dans le souci "Voir" du modèle de conception MVC. Le cas d'utilisation typique consiste à fournir une liste de tableaux à JSF. Des listes déroulantes h: selectOneMenu apparaissent dans plusieurs vues JSF. Si les données figurant dans les listes déroulantes sont spécifiques à l'utilisateur, le bean sera conservé dans l'étendue de la session. Toutefois, si les données s'appliquent à tous les utilisateurs (telles que des listes déroulantes de provinces), le bean resterait dans la portée de l'application, de sorte qu'il puisse être mis en cache pour tous les utilisateurs.
  • Utilitaire géré-Bean : Normalement le domaine d'application. Ce type de bean fournit un type de fonction "utilitaire" à un ou plusieurs vues JSF. Un bon exemple de ceci pourrait être un bean FileUpload qui peut être réutilisé dans plusieurs applications Web.
144
Paul Rivera

Excellente question. J'ai beaucoup souffert du même dilemme quand j'ai déménagé à JSF. Cela dépend vraiment de votre application. Je viens du monde Java EE. Je vous recommande donc d’avoir le moins de logique commerciale possible dans vos beans de support. Si la logique est purement liée à la présentation de votre page, c’est bien de l'avoir dans le haricot de sauvegarde.

Je pense que l’un des atouts (nombreux) de JSF réside dans le fait que vous pouvez exposer des objets de domaine directement sur les beans gérés. Je recommande donc fortement le <:outputText value="#{myBean.anObject.anObjectProperty}" />, sinon vous faites trop de travail pour exposer manuellement chaque propriété. De plus, l'insertion ou la mise à jour de données créerait un désordre si vous encapsuliez toutes les propriétés. Il existe des situations où un seul objet de domaine peut ne pas être suffisant. Dans ces cas, je prépare un ValueObject avant de l'exposer sur le haricot.

EDIT: si vous voulez encapsuler chaque propriété d’objet que vous voulez exposer, je vous recommanderais plutôt de lier les composants d’UI au bean de support, puis d’injecter le contenu directement dans la valeur du composant.

Pour ce qui est de la structure des haricots, le tournant a été pour moi lorsque j’ignorais avec force tout ce que je savais sur la création d’applications Web et commençais à le traiter comme une application à interface graphique. JSF imite beaucoup Swing et par conséquent, les meilleures pratiques pour développer des applications Swing s’appliqueraient principalement à la création d’applications JSF.

14
Allan Lykke Christensen

Je pense que la chose la plus importante avec vos haricots de sauvegarde est de séparer leurs logiques. Si vous avez une page de garde pour un système de gestion de contenu, je considérerais comme une mauvaise pratique de mettre chaque morceau de code dans un seul haricot, car:

  1. Le haricot deviendrait très gros éventuellement
  2. Il est plus facile pour les autres utilisateurs de trouver ce qu’ils cherchent s’ils résolvent la page de connexion, s’ils peuvent alors simplement rechercher le fichier loginBean.Java.
  3. Parfois, vous avez de petites fonctionnalités qui se distinguent clairement du reste de votre code. En les séparant, j'imagine que vous faciliteriez le redéveloppement/l’extension de ce code en quelque chose de plus grand, alors que vous avez déjà un haricot Nice avec une bonne structure.
  4. Avoir 1 gros haricot, pour tout faire, le rendra plus dépendant de la mémoire si/quand vous devez faire des déclarations comme celle-ci MyBigBean bigBean = new MyBigBean (); au lieu d'utiliser la fonctionnalité dont vous aviez réellement besoin, utilisez LoginBean loginBean = new LoginBean (); (Corrigez-moi si je me trompe ici ???)
  5. À mon avis, séparer vos haricots, c'est comme séparer vos méthodes. Vous ne voulez pas une grande méthode qui exécute plus de 100 lignes, mais plutôt la séparer avec de nouvelles méthodes qui gèrent leur tâche spécifique.
  6. N'oubliez pas que très probablement, quelqu'un d'autre que vous devra travailler sur vos projets JSF.

Juste mes 2 centimes à ce sujet même avec la question déjà marquée comme réponse.

4
Chris Dale

Je ne répondrais peut-être pas à toutes vos questions car peu d’entre elles semblent assez dépendantes des cas à cas.

  • C'est bien d'avoir une logique métier dans votre bean backing. Cela dépend d'où venez-vous. Si vous pratiquez la conception axée sur le domaine, vous serez tenté d'inclure la logique métier dans le bean de sauvegarde ou vous pourrez également utiliser la logique de persistance. Ils soutiennent que pourquoi objet si bête. L'objet ne devrait pas seulement contenir un état, mais aussi un comportement. D'autre part, si vous considérez la manière traditionnelle Java EE, vous pourriez avoir l'impression d'avoir des données dans votre bean de support, qui peut également être votre bean entité, et une autre logique de gestion et de persistance dans un haricot de session ou quelque chose du même genre.

  • Son parfaitement bien d'avoir un haricot simple pour toute la page. Je ne vois pas de problème avec cela seul. Cela peut ne pas sembler correct, mais cela dépend du cas.

  • Votre autre question dépend beaucoup plus du cas que vous avez en main. Je préférerais utiliser un domaine déterminé ici, il peut être approprié d’ajouter des propriétés à l’existant ou de créer un nouveau bean pour cela. Ce qui convient le mieux. Je ne pense pas qu'il y ait une solution miracle pour cela.

  • Quelles propriétés appartient à quelle haricot de sauvegarde. Eh bien, cela ne dépend-il pas de l'objet de domaine? Ou peut-être que la question n'est pas si claire.

De plus, dans votre exemple de code, je ne vois aucun avantage énorme.

4
Adeel Ansari

Je n'aurais pas besoin de ne garder qu'un seul haricot par page. Cela dépend des fonctionnalités, mais la plupart du temps, je n'avais qu'un seul haricot par page, la plupart du temps une page gérant une fonctionnalité. Par exemple, sur une page, j'ai un lien d'inscription (je vais créer un lien avec RegisterBean) et un lien de panier d'achat (ShoopingBasketBean).

J'utilise ce <: outputText value = "# {myBean.anObject.anObjectProperty}" /> comme je conserve normalement des beans de sauvegarde en tant que beans actions contenant un objet de données. Je ne veux pas écrire un wrapper dans mon bean de support pour accéder aux propriétés de mes objets de données.

4
Bhushan Bhangale

J'aime tester le code métier sans View's, je considère donc BackingBeans comme des interfaces de View à code de modèle. Je ne mets jamais aucune règle ou processus dans un BackingBean. Ce code va dans Services ou Helpers, permettant sa réutilisation.

Si vous utilisez des validateurs, mettez-les hors de votre BackingBean et faites-les référence à partir de votre méthode de validation.

Si vous accédez aux DAO pour remplir les sélections, radios, cases à cocher, faites-le toujours à partir d'un BackingBean.

Crois moi!. Vous pouvez injecter un JavaBean dans un BackingBean, mais essayez d’injecter un BackingBean dans un autre. Vous serez bientôt dans un environnement de maintenance et de compréhension du code.

0
jjruiz