Gestion des Beans

Version imprimable

10/10/2007, 10h23
Dr@ke

Gestion des Beans

J'ai essayer de regrouper le plus d'information sur la facon d'utiliser les beans... beaucoup utilisent des design patterns (par exemple), sur mon application je ne m'en suis pas preocuppe mais je commence a me poser des questions...

Mon appli comporte pour le moment 5 beans sessions, une par classe principale. Chacune d'entre elles a ses fonctions CRUD, et d'autres fonctions necessaires par exemple a la creation de listes etc...

Je me demande quelle est la limite des Beans, ou la bonne methode a adopter pour que je ne me retrouve pas avec des PermGen space errors a la fin de mon projet...

Quelqu'un aurait-il une experience interessante sur ce propos ? Merci.
10/10/2007, 10h47
romaintaz

Citation:

Envoyé par Dr@ke

Mon appli comporte pour le moment 5 beans sessions, une par classe principale. Chacune d'entre elles a ses fonctions CRUD

Ca veut dire que tes beans se chargent directement des accès à la base de données ?
Là, c'est pas cool, il est préférable que les beans demandent à des services (qui sont connectés aux DAO) pour ces opérations en base...

Je pense que oui, mes beans sont charges avec les donnees recuperes par les requetes Hibernate, et se modifient eux meme dans la base...

exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class Client { public String editer () { HibernateUtil.editer(this); return "naviVieCli"; } public String supprimer () { this.setActif(false); this.editer(); this.clean(); return ("naviVieCli"); } }
Donc ce n'est pas le bon moyen pour faire ca ?
Je suis encore assez nouveaux sur ces design patterns/web services, j'ai fait quelques recherches sur le net a ce propos, corrige moi si j'ai faux ou rajoute des details :)

Donc un DAO est une classe intermediaire entre mes beans et ma base de donnee. Elle sert a separer le code utile et les requetes sql. (ce sont pas les classeHome crees par Hibernate par hasard ??)
Dans mes beans je garde les infos basiques et des fonctions qui n'ont rien avoir avec la BDD, dans le DAO il y a les actions CRUD.
Par contre, que represente la partie service ?
Lorsque je veux supprimer un bean, dans la partie action=#{xx.delete}, xx represente donc le bean ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 class client { supprimer () { clientService.supprimer (this); } class clientService { supprimer (Client c) { clientDAO.supprimer (c); { } class clientDAO { supprimer (Client c) { HibernateUtil.supprimer(c); }
La couche service ne sert pas trop ici, j'ai du mal comprendre son utilite vu que pour chaque fonction service, je dois l'appeler depuis le bean.

J'ai par ailleurs compris pourquoi j'obtiens parfois une erreur : lazy loading lorsque j'essaye d'acceder a une collection ou une classe d'un bean... Si j'ai une entreprise avec une liste de client, et chaque client possede une liste de contrats etc... le mapping ne load les informations que jusqu'a un certain niveau...
A quelle endroit preciser cette profondeur ?

Apres avoir tout modeliser, je me retrouverai toujours avec mes 4 beans sessions (mais sans fonctions encombrantes), c'est bien ca ?

J'etais completement a cote de la plaque jusqu'a present :aie:

10/10/2007, 13h18
djo.mos
Bonjour.
En ce qui concerne l'architecture, voici une vue d'ensemble rapide :
- La couche DAO : encapsulent la communication avec la BD (les 4 opérations CRUD) :arrow: fait partie de la couche Model.
- Les managed beans : exposent les données aux pages JSF ainsi que la gestion de la logique de navigation entre les pages (avec le faces-config.xml) :arrow: la partie Controller.
- La couche Service : Très négligée pourtant cruciale pour réaliser une application propre : Elle agit en adaptateur entre la couche DAO et le Controller. Elle offre des services de haut niveau par rapport à la couche DAO :arrow: c'est là que doit résider la logique metier de ton application. :arrow: fait partie de la couche Model.
Exemple : Gestion d'un clinique.
- A la création d'un compte pour un patient par exemple, une DAO n'est pas suffisante. En effet, il faut par exemple vérifier que les coordonnées du patient sont uniques, etc.
- A la création d'une visite, il faut sélectionner un médecin libre dans une tranche horaire donnée, créer une entité Visite, renseigner ses champs avec un médecin et un patient, etc.
Ces quelques exemples montrent que la DAO seule n'est pas suffisante pour gérer la logique métier d'une application :arrow: Au lieu de coder ça à la bourrine (insertion des traitements métier dans la DAO et/ou dans les managed beans) mieux vaut passer par la couche services.

pour plus de détails (ce sujet a été pas mal abordé dans nos forums), je te propose les liens suivants (vers des discussions dans nos forums):

http://www.developpez.net/forums/sho...d.php?t=370054
http://www.developpez.net/forums/sho...d.php?t=341618

En ce qui concerne les problèmes liés au Lazy Fetch, ce n'est pas du tout ce que tu crois : Il n'y a aucune restrictions quant à la profondeur qu'on peut atteindre, c'est tout un autre problème.
Voici la discussion qui en parle :
http://www.developpez.net/forums/sho...d.php?t=343249

Bonne chance.
10/10/2007, 14h08
romaintaz

Je crois que tout a été dit par mjo.dos !
D'ailleurs, je te remercie pour le lien vers la discussion sur la LazyInitialization, parce que je rencontre ce problème sur mon application... A lire attentivement donc !

Je confirme donc qu'il faut éloigner le bean de tout ce qui est règles métiers (prises en charge par les services) ou les opérations en base (prises en charge par les DAO et les frameworks du style Hibernate)...
Même si ton application est simple, il est recommandé de conserver ce type d'architecture, plus propre, plus facile à maintenir. Et puis comme ça, on prend des bonnes habitudes pour la suite :mrgreen:
10/10/2007, 14h23
djo.mos

Citation:

Envoyé par romaintaz

mjo.dos

:mouarf:
10/10/2007, 14h52
heid

Contrenative nomipetrie

comprendra qui pourra ;)
10/10/2007, 15h14
romaintaz

Citation:

Envoyé par djo.mos

:mouarf:

C'était involontaire tellement c'était pas voulu.
Aussi, quelle idée d'avoir des pseudos pareil :roll:

Je vais bien entendu utiliser cette architecture si autant d'experts me le conseillent :)
Je suis en train de brasser toute cette masse d'information en les testant sur mon projet. Et je suis un peu perdu parce que ca change tout sur la facon dont je procedais !! T_T

En comprenant ceci, je devrais avoir compris tout le reste :
Prenons une page avec une selectOneMenu, liste d'entreprise.
Lors de la selection d'une entreprise, j'effectue une action, qui affiche les infos de cette entreprise en dessous...
Un lien edition sur un menu a cote, qui edite l'entreprise selectionnee.

Mon ancienne demarche (tres moche donc :p) :
Code:

1 2 3 4 5 6 7 <h:selectOneMenu onchange="submit()" immediate="true" valueChangeListener="#{entreprise.changeSelection}"> <f:selectItems value="#{beanctrl.entList}" /> </h:selectOneMenu> <h:outputText rendered="#{entreprise.rendered}" value="#{entreprise.nomEnt}" />
beanctrl etait un bean request qui effectuait certaines operations (ici entList renvoie la list des entreprises en accedant a la DB)

entreprise est un bean session, changeSelection met a jour ce bean en recuperant les infos dans la BD (a partir du nom) et les mettant un a un dans le bean actuel...

L'edition appele la fonction entreprise.edit (sans probleme vu que l'entreprise est en session)

Bon, lancez les tomates, allez y..:aie:

La nouvelle demarche :king: (ou plutot comme je l'ai compris) :
Un bean entreprise, je suppose qu'il est toujours la pour afficher ses donnees... je le mettrai bien en request mais apres, lorsque je cliquerai sur le lien edition, je voudrais savoir quelle entreprise j'avais en main ! Donc je le met en session pour le moment..

Mais maintenant, par qui passer ? Prenons l'action changeSelection, je suppose que je dois appeler le EntrepriseDao.findById mais par qui ?
Par le bean entreprise, qui appele le service associe, qui appele le Dao ?
Par le service entreprise, mais qui ensuite n'a plus de reference vers le bean entreprise...

Ensuite, une fois trouve, dans l'exemple Struts, il met manuellement le bean dans la mapSession, je suppose que je peux faire la meme chose, mais je trouve ca bizzare :)

Ce sont surement des questions betes mais vu que je suis passe par un tout autre chemin, je n'arrive pas a me representer ceci !!
Merci 42000 fois pour votre aide..

10/10/2007, 16h02
romaintaz

En gros, ton bean va avoir des liens vers tous les services dont il a besoin.

Donc dans ton cas, le bean a un lien vers EntrepriseService qui propose une méthode par exemple findAllEnterprises(). Le service, quant à lui, dispose d'un lien vers le DAO EntrepriseDao, et va donc utiliser la méthode EntrepriseDao.findById.

Ce qui donne grossièrement :

Page JSF -> Bean -> Service -> DAO (-> Hibernate ou autre) -> Base de données (-> Hibernate ou autre) -> DAO -> Service -> Bean -> Page JSF.
10/10/2007, 16h11
Dr@ke

Ca m'a l'air parfait comme explication !
Donc un seul bean (pour l'entreprise) devrait suffire dans la page JSF, et je l'utilise comme ceci : action="#{entreprise.service.findAll}"

Non, je ne trouve pas très propre l'appel direct à des services directement dans la page JSF.
Passe par des actions ou des getters de ton Bean.

Pour avoir la liste de tes entreprises, tu fais dans le JSF :

Code:

1
2
3
4
5
6
 
...
    <h:selectOneMenu value="#{monBean.entrepriseSelectionnee}">
        <f:selectItems value="#{monBean.listeEntreprises}"/>
    </h:selectOneMenu>
...

Dans ton bean :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
    ...
    public List<SelectItem> getListeEntreprises() {
        if (this.listeEntreprises == null) {
            listeEntreprises = new ArrayList<SelectItem>();
           List<Entreprise> list = entrepriseService.findAllEntreprises();
            for (Entreprise e : list) {
                listeEntreprises.add(new SelectItem(e.getId(), e.getLabel()));
            }
        }
        return this.listeEntreprises;
    }
    ...

10/10/2007, 16h27
Dr@ke

Mais je pensais que l'interet principal de cette maniere de faire etait de n'avoir QUE les attributs/getters/setters dans le managed bean...
Etant donne que la liste d'enteprise n'est pas un attribut "naturel" dans cette classe...
C'est pour cela que je ne comprenais pas, je ne voulais pas rajouter de code dans la classe Entreprise..

Je pense que je comprend tout maintenant...merci a vous !
10/10/2007, 16h44
romaintaz
En fait le bean créé la liste dans mon exemple pour une raison simple, c'est que la liste est une liste de SelectItem, qui sont des éléments purement destinés à la présentation. La création de la liste n'aurait donc aucun sens au niveau des services ou des DAO...

En gros, je vois les classes suivantes pour ton cas :
- Entreprise: La classe de base, celle qui mappe la table Entreprise en base de données.
- EntrepriseDao (et EntrepriseDaoImpl) pour les DAO. EntrepriseDao étant une interface, EntrepriseDaoImpl son implémentation. Eux se chargent de l'accès à la base de données, via Hibernate ou pas, selon ce que tu utilises.
- EntrepriseService et EntrepriseServiceImpl. Elles fournissent toutes les méthodes business liées à l'objet Entreprise.
- EntrepriseBean, qui est le bean lié à ta page JSF.
J'espère que ça se clairifie maintenant :P
10/10/2007, 17h14
Dr@ke

Ah tu me rajoute encore un bean la :)
Celui qui est lie a la page JSF.. Moi je liais la classe de base en mode session..
Toi je suppose que EntrepriseBean a une reference vers la classe de base ET en meme temps vers le service... Et c'est lui qui gere les rules de navigation en toute logique.

Cela permet une separation plus propre, c'est vrai !
10/10/2007, 17h36
djo.mos

Non, c'est pas ça : EntrepriseBean est le managed bean exposé aux pages JSF (perso, je l'appèle plutôt EntrepriseController pour éviter la confusion avec tous ces MachinBean). Le service est représenté par EntrepriseService et son implémentation.
Remarques que t'es pas vraiment obligé de passer par des interfaces, mais dans l'absolu, ça assure une belle séparation entre les différents couches de ton application.

Aussi, pour les DAOs, tu peux te contenter d'une seule interface mais qui soit paramétrée (avec les generics de Java 5.0).
10/10/2007, 17h55
Dr@ke

En effet c'est la confusion totale avec tous ces beans...
Donc c'est l'entrepriseController qui possede les regles de navigation et qui stocke toutes les donnees utiles a la page actuelle.
Derniere question...a qui est liee la classe de base dans ce cas.. ?

Controller -> Service -> Dao

Je l'ai mise dans le Controller, et cela m'a l'air de bien marcher..