116 votes

Structure des beans de soutien JSF (meilleures pratiques)

J'espère que dans ce post, je pourrai obtenir l'avis des gens sur les meilleures pratiques pour l'interface entre les pages JSF et les backing beans.

Une chose que je n'arrive jamais à régler, c'est la structure de mes haricots de soutien. De plus, je n'ai jamais trouvé un bon article sur le sujet.

Quelles propriétés appartiennent à quels backing beans ? Quand est-il approprié d'ajouter des 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 de n'avoir qu'un seul bean de sauvegarde pour toute la page, compte tenu de la complexité de l'injection d'un bean dans un autre ? Le backing bean doit-il contenir une véritable logique métier ou uniquement des données ?

N'hésitez pas à répondre à ces questions et à toute autre question qui pourrait vous être posée.


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

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

Je demande toujours quelque chose comme :

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

avec une valeur de backing bean de :

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

Lorsque je boucle sur une collection, j'utilise une classe enveloppe pour éviter d'avoir à forer dans un objet d'une table de données, par exemple.

En général, cette approche me semble "juste". Elle évite tout couplage entre la vue et les données. Veuillez me corriger si je me trompe.

0voto

jjruiz Points 1

J'aime tester le code métier sans les vues, c'est pourquoi je considère les BackingBeans comme des interfaces entre la vue et le code du modèle. Je ne mets jamais de règle ou de processus dans un BackingBean. Ce code va dans les Services ou les Helpers, permettant la réutilisation.

Si vous utilisez des validateurs, mettez-les en dehors de votre BackingBean et référencez-les à partir de votre méthode de validation.

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

Croyez-moi ! Vous pouvez injecter un JavaBean dans un BackingBean, mais essayez d'injecter un BackingBean dans un autre. Vous serez bientôt dans un nigntmare de maintenance et de compréhension du code.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X