IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JSF Java Discussion :

Gestion des Beans


Sujet :

JSF Java

  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 91
    Par défaut 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.

  2. #2
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Par défaut
    Citation Envoyé par Dr@ke Voir le message
    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...
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 91
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  4. #4
    Expert confirmé
    Avatar de djo.mos
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2004
    Messages : 4 666
    Par défaut
    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) 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) 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 c'est là que doit résider la logique metier de ton application. 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 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.

  5. #5
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Par défaut
    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
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  6. #6
    Expert confirmé
    Avatar de djo.mos
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2004
    Messages : 4 666
    Par défaut
    Citation Envoyé par romaintaz Voir le message
    mjo.dos

  7. #7
    Membre chevronné Avatar de heid
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    388
    Détails du profil
    Informations personnelles :
    Localisation : France, Indre et Loire (Centre)

    Informations forums :
    Inscription : Mai 2002
    Messages : 388
    Par défaut
    Contrenative nomipetrie

    comprendra qui pourra

  8. #8
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Par défaut
    Citation Envoyé par djo.mos Voir le message
    C'était involontaire tellement c'était pas voulu.
    Aussi, quelle idée d'avoir des pseudos pareil
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  9. #9
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 91
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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..

    La nouvelle demarche (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
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Par défaut
    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.
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  11. #11
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 91
    Par défaut
    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}"

  12. #12
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    ...
        <h:selectOneMenu value="#{monBean.entrepriseSelectionnee}">
            <f:selectItems value="#{monBean.listeEntreprises}"/>
        </h:selectOneMenu>
    ...
    Dans ton bean :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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;
        }
        ...
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  13. #13
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 91
    Par défaut
    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 !

  14. #14
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Par défaut
    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
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  15. #15
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 91
    Par défaut
    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 !

  16. #16
    Expert confirmé
    Avatar de djo.mos
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2004
    Messages : 4 666
    Par défaut
    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).

  17. #17
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2003
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2003
    Messages : 91
    Par défaut
    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..

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. BeanUtils Gestion des beans complexes et des listes
    Par CPI_en_mousse dans le forum Général Java
    Réponses: 3
    Dernier message: 03/07/2015, 11h59
  2. Gestion des managed beans (scope, ajax etc.)
    Par Malone dans le forum JSF
    Réponses: 4
    Dernier message: 26/06/2009, 16h30
  3. Gestion des variables - mémoire ?
    Par RIVOLLET dans le forum Langage
    Réponses: 4
    Dernier message: 26/10/2002, 12h44
  4. Réponses: 4
    Dernier message: 04/07/2002, 12h31
  5. c: gestion des exceptions
    Par vince_lille dans le forum C
    Réponses: 7
    Dernier message: 05/06/2002, 14h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo