Structure des beans de soutien JSF (meilleures pratiques)

Question

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.

Answer 1

Vous pourriez vouloir vérifier ceci : faire des distinctions entre les 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 susmentionné de Neil Griffin :

• Modèle Managed-Bean : Normalement, la portée de la session. Ce type de managed-bean participe à la préoccupation "Modèle" du modèle de conception MVC. Lorsque vous voyez le mot "modèle", pensez à DATA. Un bean de modèle JSF doit être un POJO qui suit le modèle de conception JavaBean avec des getters/setters encapsulant les propriétés. Le cas d'utilisation le plus courant pour un bean de modèle est d'être une entité de base de données, ou de représenter simplement un ensemble de lignes à partir de l'ensemble des résultats d'une requête de base de données.
• Backing Managed-Bean : Normalement, la portée de la demande. Ce type de managed-bean participe à la préoccupation "View" du modèle de conception MVC. Le but d'un backing-bean est de prendre en charge la logique de l'interface utilisateur, et il a une relation 1::1 avec une vue JSF, ou un formulaire JSF dans une composition Facelet. Bien qu'il possède généralement des propriétés de type JavaBean avec des getters/setters associés, il s'agit de propriétés de la vue et non du modèle de données de l'application sous-jacente. Les backing-beans JSF peuvent aussi avoir des méthodes JSF actionListener et valueChangeListener.
• Contrôleur Managed-Bean : Normalement, la portée de la demande. Ce type de bean géré participe à la préoccupation "contrôleur" du modèle de conception MVC. L'objectif d'un bean contrôleur est d'exécuter un certain type de logique métier et de renvoyer un résultat de navigation au gestionnaire de navigation JSF. Les controller-beans 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 haricot "supporte" une ou plusieurs vues dans la préoccupation "View" du modèle de conception MVC. Le cas d'utilisation typique est la fourniture d'une ArrayList aux listes déroulantes JSF h:selectOneMenu qui apparaissent dans plus d'une vue JSF. Si les données des listes déroulantes sont propres à l'utilisateur, le bean sera conservé dans la portée de la session. En revanche, si les données s'appliquent à tous les utilisateurs (par exemple, des listes déroulantes de provinces), le bean est conservé dans le champ d'application, afin qu'il puisse être mis en cache pour tous les utilisateurs.
• Utilitaire Managed-Bean : Normalement, le champ d'application. Ce type de haricot fournit un certain type de fonction "utilitaire" à une ou plusieurs vues JSF. Un bon exemple serait un bean FileUpload qui peut être réutilisé dans plusieurs applications Web.

Answer 2

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

Je pense que l'une des (nombreuses) forces de JSF est en fait le fait que vous pouvez exposer des objets de domaine directement sur les beans gérés. C'est pourquoi je recommande vivement l'utilisation de l'option <:outputText value="#{myBean.anObject.anObjectProperty}" /> sinon vous finirez par vous compliquer la tâche en exposant manuellement chaque propriété. De plus, si vous encapsulez toutes les propriétés, ce sera un peu la pagaille lors de l'insertion ou de la mise à jour des données. Il y a des situations où un seul objet de domaine peut ne pas être suffisant. Dans ces cas, je prépare un Objet de valeur avant de l'exposer sur le haricot.

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

En termes de structure de haricot, le tournant pour moi a été lorsque j'ai ignoré avec force toutes les choses que je savais sur la construction d'applications web et que j'ai commencé à les traiter comme des applications GUI. JSF imite beaucoup Swing et, par conséquent, les meilleures pratiques pour développer des applications Swing s'appliquent également à la construction d'applications JSF.

Answer 3

Il n'est pas nécessaire de ne conserver qu'un seul haricot de fond par page. Cela dépend de la fonctionnalité mais la plupart du temps, j'ai un bean par page car la plupart du temps, une page gère une fonctionnalité. Par exemple, sur une page, j'ai un lien d'enregistrement (je vais le lier avec RegisterBean) et un lien de panier d'achat (ShoopingBasketBean).

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

Answer 4

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 pense que c'est une mauvaise pratique que de mettre chaque morceau de code dans un seul bean :

1. Le haricot deviendrait très gros par la suite
2. Il est plus facile pour les autres personnes de trouver ce qu'elles cherchent si elles sont en train de dépanner la page de connexion, si elles peuvent alors facilement chercher le fichier loginBean.java.
3. Parfois, vous avez de petits morceaux de fonctionnalité qui sont clairement distincts du reste de votre code, en les séparant, 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 beau haricot avec une bonne structure.
4. Le fait d'avoir un seul 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 funksjonalité dont vous avez 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 s'étend sur des centaines de lignes, mais plutôt la diviser avec de nouvelles méthodes qui gèrent leur tâche spécifique.
6. N'oubliez pas qu'il est fort probable que quelqu'un d'autre que vous doive également travailler sur vos projets JSF.

---

En ce qui concerne le couplage, je ne vois pas de problème à permettre à vos pages JSF d'accéder aux propriétés des objets de votre backingbean. Il s'agit d'un support qui est intégré à JSF, et qui le rend plus facile à lire et à construire. Vous séparez déjà strictement la logique MVC. En faisant cela, vous vous épargnez des tonnes de lignes avec des getters et setters dans votre backingbean. Par exemple, j'ai un objet vraiment énorme qui m'a été donné par les services web, et j'ai besoin d'utiliser certaines propriétés dans ma présentation. Si je devais faire un getter/setter pour chaque propriété, mon bean s'étofferait d'au moins 100 lignes supplémentaires de variables et de méthodes pour obtenir les propriétés. En utilisant la fonctionnalité intégrée de JSF, je gagne du temps et économise de précieuses lignes de code.

C'est juste mon avis sur le sujet, même si la question a déjà reçu une réponse.

Answer 5

Il se peut que je ne réponde pas à toutes vos questions, car certaines semblent dépendre du cas par cas.

• C'est bien d'avoir une logique d'entreprise dans votre haricot de soutien. Cela dépend de votre point de vue. Si vous pratiquez la conception orientée domaine, vous serez tenté d'inclure la logique métier dans le backing bean ou peut-être aussi dans la logique de persistance. Ils argumentent que pourquoi un objet si bête. L'objet ne devrait pas seulement porter 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 backing bean, qui peut aussi être votre entity bean, et d'autres logiques d'entreprise et de persistance dans un session bean ou autre. C'est bien aussi.

• Il est tout à fait normal d'avoir un seul haricot de sauvegarde pour toute la page. Je ne vois pas de problème avec ce seul élément. 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 que l'on s'oriente vers le domaine ici, il pourrait être approprié d'ajouter des propriétés à l'existant ou bien de créer un nouveau bean pour cela. Ce qui convient le mieux. Je ne pense pas qu'il y ait de solution miracle pour cela.

• Quelles propriétés appartiennent à quel haricot de sauvegarde. Cela ne dépend-il pas de l'objet de domaine ? Ou peut-être que la question n'est pas aussi claire.

De plus, dans l'exemple de code que vous avez donné, je ne vois pas de gros avantages.