Structure du backing bean JSF (bonnes pratiques)

J'espère que dans cet article, je pourrai avoir l'opinion des gens sur les meilleures pratiques pour l'interface entre les pages JSF et les backing beans.

Une chose sur laquelle je ne pourrai jamais m'arrêter est la structure de mes backing beans. 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 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 de n'avoir qu'un seul bean de support pour toute la page, compte tenu de la complexité de l'injection d'un bean 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 à toutes autres qui pourraient survenir.

---

En ce qui concerne la réduction du couplage entre la page JSF et le backing bean, je n'autorise jamais la page JSF à accéder aux propriétés des propriétés du backing bean. 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 backing bean de:

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

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

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

Vous voudrez peut-être vérifier ceci: faire des distinctions entre les différents types de beans gérés 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 : normalement la portée de la session. Ce type de gestion-bean participe à la préoccupation «Model» du design pattern MVC. Lorsque vous voyez le mot «modèle», pensez aux DONNÉES. Un bean-modèle JSF doit être un POJO qui suit le modèle de conception JavaBean avec des getters / setters encapsulant des propriétés. Le cas d'utilisation le plus courant d'un bean modèle est d'être une entité de base de données ou simplement de représenter un ensemble de lignes à partir du jeu de résultats d'une requête de base de données.
• Backing Managed-Bean : normalement demander la portée. Ce type de gestion-bean participe à la préoccupation "View" du design pattern MVC. Le but d'un backing-bean est de prendre en charge la logique de l'interface utilisateur et a une relation 1 :: 1 avec une vue JSF ou un formulaire JSF dans une composition Facelet. Bien qu'il ait généralement des propriétés de style JavaBean avec des getters / setters associés, ce sont des propriétés de la vue et non du modèle de données d'application sous-jacent. Les backing-beans JSF peuvent également avoir des méthodes JSF actionListener et valueChangeListener.
• Controller Managed-Bean : normalement demander la portée. Ce type de gestion-bean participe à la préoccupation «Controller» du design pattern MVC. Le but 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 beans-contrôleurs JSF ont généralement des méthodes d'action JSF (et non des méthodes actionListener).
• Support Managed-Bean : normalement la portée de la session ou de l'application. Ce type de bean "prend en charge" une ou plusieurs vues dans la préoccupation "Vue" du modèle de conception MVC. Le cas d'utilisation typique est de fournir une ArrayList à JSF h: selectOneMenu listes déroulantes qui apparaissent dans plusieurs vues JSF. Si les données des listes déroulantes sont propres à l'utilisateur, le bean serait conservé dans la portée de la session. Cependant, si les données s'appliquent à tous les utilisateurs (comme une liste déroulante de provinces), alors le bean serait conservé dans la portée de l'application, de sorte qu'il puisse être mis en cache pour tous les utilisateurs.
• Utilitaire Managed-Bean : normalement le champ d'application. Ce type de bean fournit un type de fonction "utilitaire" à une ou plusieurs vues JSF. Un bon exemple de cela pourrait être un bean FileUpload qui peut être réutilisé dans plusieurs applications Web.

Excellente question. J'ai beaucoup souffert du même dilemme lorsque j'ai rejoint JSF. Cela dépend vraiment de votre application. Je viens du monde Java EE donc je recommanderais d'avoir le moins de logique métier possible dans vos backing beans. Si la logique est purement liée à la présentation de votre page, alors c'est bien de l'avoir dans le backing bean.

Je pense que l'un des (nombreux) atouts de JSF est en fait le fait que vous pouvez exposer des objets de domaine directement sur les beans gérés. Je recommanderais donc fortement l' <:outputText value="#{myBean.anObject.anObjectProperty}" />approche, sinon vous finirez par faire trop de travail pour vous-même en exposant manuellement chaque propriété. De plus, ce serait un peu compliqué lors de l'insertion ou de la mise à jour des données 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 bean.

EDIT: En fait, si vous allez encapsuler chaque propriété d'objet que vous souhaitez exposer, je vous recommanderais plutôt de lier les composants de l'interface utilisateur au bean de support, puis d'injecter le contenu directement dans la valeur du composant.

En termes de structure de bean, le tournant pour moi a été lorsque j'ai ignoré avec force tout ce que je savais sur la création d'applications Web et que j'ai commencé à le traiter comme une application graphique. JSF imite beaucoup Swing et, par conséquent, les meilleures pratiques pour le développement d'applications Swing s'appliqueraient principalement à la création d'applications JSF.

Je pense que la chose la plus importante avec vos backing beans est de séparer leurs logiques. Si vous avez une page d'accueil pour un système CMS, je considérerais comme une mauvaise pratique de mettre chaque morceau de code dans un seul bean car:

1. Le haricot finirait par devenir très gros
2. Il est plus facile pour d'autres personnes de trouver ce qu'elles recherchent si elles résolvent les problèmes de la page de connexion, si elles peuvent ensuite facilement rechercher le fichier loginBean.java.
3. Parfois, vous avez de petites fonctionnalités qui sont clairement distinctes du reste de votre code, en séparant cela, j'imagine que vous vous faciliteriez la tâche pour redévelopper / étendre ce code en quelque chose de plus grand, alors que vous avez déjà un bon bean avec du bon structure.
4. Avoir 1 gros bean, 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 fonction funksjonality dont vous aviez réellement besoin en faisant 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 d'une grande méthode qui exécute plus de 100 lignes, mais la divisez plutôt avec de nouvelles méthodes qui gèrent leur tâche spécifique.
6. N'oubliez pas que quelqu'un d'autre que vous devra probablement travailler sur vos projets JSF.

---

En ce qui concerne le couplage, je ne vois pas cela comme un problème gênant pour permettre à vos pages JSF d'accéder également aux propriétés des objets de votre backingbean. Il s'agit d'un support intégré à JSF et qui facilite vraiment la lecture et la construction de imo. Vous séparez déjà strictement la logique MVC. En faisant cela, vous économisez des tonnes de lignes avec des getters et des setters dans votre backingbean. Par exemple, j'ai un objet vraiment énorme qui m'est donné par les services Web, où je dois utiliser certaines propriétés dans ma présentation. Si je devais créer un getter / setter pour chaque propriété, mon bean se développerait avec au moins 100 lignes supplémentaires de variables et de méthodes pour obtenir les propriétés. En utilisant la fonctionnalité JSF intégrée, mon temps et mes précieuses lignes de code sont épargnés.

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

Je ne répondrai peut-être pas à chacune de vos questions, car peu d'entre elles semblent dépendre d'un cas à l'autre.

• C'est bien d'avoir une logique métier dans votre backing bean. Cela dépend d'où tu viens. Si vous pratiquez la conception pilotée par domaine, vous serez tenté d'inclure la logique métier dans le backing bean ou peut-être aussi la logique de persistance. Ils soutiennent que pourquoi objet si stupide. L'objet doit porter non seulement l'état mais aussi le comportement. D'un autre côté, si vous considérez la manière traditionnelle de faire les choses de Java EE, vous pourriez avoir envie d'avoir des données dans votre bean de sauvegarde, qui peut également être votre bean entité, et d'autres logiques commerciales et de persistance dans un bean session ou quelque chose. C'est bien aussi.

• C'est parfaitement bien d'avoir un seul bean de support pour toute la page. Je ne vois aucun 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 le domaine ici, il pourrait être approprié d'ajouter des propriétés à l'existant ou de créer un nouveau bean pour cela. Ce qui convient toujours mieux. Je ne pense pas qu'il y ait de solution miracle pour cela.

• Quelles propriétés appartiennent à quel backing bean. Eh bien, cela ne dépend pas de l'objet de domaine? Ou peut-être que la question n'est pas si claire.

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

Je n'aurais pas besoin de garder un seul backing bean par page. Cela dépend de la fonctionnalité, mais la plupart du temps, j'avais un bean par page, car la plupart du temps, une page gérait une fonctionnalité. Par exemple, sur une page, j'ai un lien d'inscription (je vais créer un lien avec RegisterBean) et un lien vers le panier (ShoopingBasketBean).

J'utilise ce <: outputText value = "# {myBean.anObject.anObjectProperty}" /> car je continue normalement à sauvegarder des beans comme des beans d'action qui contiennent des objets de données. Je ne veux pas écrire de wrapper dans mon bean de sauvegarde pour accéder aux propriétés de mes objets de données.

J'aime tester le code métier sans View, donc je considère BackingBeans comme des interfaces du code View au Model. Je n'ai jamais mis de règle ou de processus dans un BackingBean. Ce code entre dans les Services ou Helpers, permettant la réutilisation.

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

Si vous accédez aux DAO pour remplir Selects, Radios, Checkboxes, 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 une phase de maintenance et de compréhension du code.