Discussion :

[Dr@ke]

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.

[romaintaz]

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...

[Dr@ke]

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

[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) 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.

[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

[djo.mos]

mjo.dos