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

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  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

+ 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