Discussion :

[libuma]

Bonjour,

C'est la première fois que j'utilise Spring, j'expérimente donc un peu la chose.

Je veux créer un formulaire avec différents menus déroulants.
Prenons par exemple une liste de clients et une liste de produits proposés.

Pour l'instant, dans mon controller, j'ai une instance de clientManager et de ProductManager avec leurs getters & setters.
Dans chacune de ces classes managers, j'ai une instance de clientDAO et productDAO et leurs getters & setters.
Dans ces daos, j'ai une méthode getList qui va me récupérer la liste désirée.
(Précision, j'utilise Hibernate et Criterion)

J'ai bien sûr un fichier de config qui reférence les beans appropriés pour injecter les dépendances..

ça fonctionne mais j'ai plusieurs questions :

1) Chaque fois que j'ai un controlleur qui manipule des objets venant de tables différentes, vais-je devoir avoir des setManagers & getManagers pour chacun d'eux ? (ex: Form avec 10 listes -> 10 setters & 10 getters ?)

2) Si je ne fais jamais QUE lire (récupérer) ma liste de produits, que je ne dois jamais faire d'update/delete/insert, dois-je malgré tout passer par un Manager ?

3) La structure actuelle est-elle propre ?

Merci d'avance pour votre réactivité !

[ray_fab]

Bonsoir la réponse à ta première question est non, tu n'es pas obligé de préciser les getters et les setters une fois que tes classes dao sont déclarées dans le conteneur de Spring. il suffit de les precédés de l'annotation @Autowired ou @Resource, leur utilisation dépends de toi...Cela est valable pour toutes les classes qui sont déclarées dans les conteneurs.
Ta deuxième question est mal posée, mais tu crois qu'il existe une magie sans utiliser les dao ou les manager, se connecter à la base de données récupérer des objets?Si cela était possible le design pattern DAO ne devrait pas exister, Hibernate devient inutile, donc si jai bien compris ta question la réponse est oui tu dois passer par le manager sinon reformule la.

[libuma]

Effectivement, Autowired est pas mal
Merci pour ta réponse.

Par contre, pourquoi autant de sarcasme pour la deuxième question?
Entre nous, un manager n'est qu'une classe qui fait le lien entre le controlleur et le DAO, on pourrait très bien s'en passer (pas propre..).
De plus, Des frameworks comme spring permettent d'utiliser un controlleur propre au framework, qu'on doit juste définir et qu'on ne doit même plus créer...
Alors, pourquoi pas ? Je ne connais pas encore spring, je m'informe...

Je ne comprends pas pourquoi ce genre de réaction..

[ray_fab]

Désolé si tu as mal pris ma réponse.
En fait pourquoi utiliser un Service, l'objectif est d'apporter une séparation totale entre les différentes couches d'une application, c'est à dire la couche Web ne doit rien savoir sur la couche Dao, le contrôleur ne doit pas se soucier de savoir d'où viennent les données dont on lui donne et où vont les données qu'il donne au Service, et la couche Dao ne doit pas non plus savoir d'où proviennent les données et où vont elles. Cela permet de garantir la flexibilité pour les données donc l'application. Si un Service n'était pas essentiel, on ne se préoccupera pas de créer sa couche, qui est le centre d'une application. Maintenant avoir une couche Service ou non ne dépends que de toi et de ce que t'as envie de faire.

[libuma]

Oui tout à fait d'accord...
Simplement, 10 Managers, 10 DAO, pour un form me semblait beaucoup, d'où ma question.
C'est vrai qu'en utiliser déjà @Autowired, on a 10 getters & 10 setters en moins, la classe est déjà plus propre

[libuma]

Petite question,
J'ai donc deux DAOs qui gère chacune une table :

• Atmosphère
• Satisfaction

Est-ce que c'est plus propre de créer un Manager pour chacun d'eux Comme ceci...

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
19
20
21
22
23
24
25
26
27
28
29
30
 
@Transactional (readOnly=true, propagation=Propagation.REQUIRED)
public class SatisManager{ 
 
	@Autowired
	private SatisDao satisDao = null;
 
	public List<Satisfaction> getSatisList() {
		return satisDao.getSatisList();
	}	
 
	public Satisfaction getSatisById(Long id) {
		return satisDao.getSatisById(id);
	}
}
 
@Transactional (readOnly=true, propagation=Propagation.REQUIRED)
public class AtmosManager{ 
 
	@Autowired
	private AtmosManagersatisDao = null;
 
	public List<Atmosphere> getAtmosList() {
		return atmosDao.getAtmosList();
	}	
 
	public Atmosphere getAtmosById(Long id) {
		return atmosDao.getAtmosById(id);
	}
}

Ou est-ce que cela à du sens de les rassembler dans le même manager comme ceci :

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
19
20
21
22
23
24
25
 
@Transactional (readOnly=true, propagation=Propagation.REQUIRED)
public class DetailManager{ 
 
	@Autowired
	private SatisDao satisDao = null;
             private AtmosDao atmosDao = null;
 
 
	public List<Satisfaction> getSatisList() {
		return satisDao.getSatisList();
	}	
 
	public Satisfaction getSatisById(Long id) {
		return satisDao.getSatisById(id);
	}
            public List<Atmosphere> getAtmosList() {
		return atmosDao.getAtmosList();
	}	
 
	public Atmosphere getAtmosById(Long id) {
		return atmosDao.getAtmosById(id);
	}
 
}

Sachant que ce sont tous deux des éléments "détails" qu'on utilisera en readonly.
Ou même un manager commun et un DAO commun ?
La chose importante à savoir est : A quelle moment Hibernate effectue-t-il ses connexions vers la base de données ? (pour éviter les accès inutiles et donc les ralentissement...
Seulement quand il accède aux méthodes du DAO je suppose?

Merci d'avance!

[ray_fab]

Oui tout à fait d'accord...
Simplement, 10 Managers, 10 DAO, pour un form me semblait beaucoup, d'où ma question.

Tu peux créer un DAO et un Manager générique donc pas besoin de créer une implémentation pour chaque classe persistante.
Par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public interface IDao<R>{
         public void save(R r);
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
public class Dao<R> implements IDao<R>{
         public void save(R r){
                  em.persist(r);
                 //session.save(r);
        }
}

Perso je n'utilise plus une classe générique de cette manière car elle implique de créer pas 10 implémentations mais 10 instances de la classe Dao c'est déjà mieux vu qu'on peux ne pas avoir à utiliser toutes les classes persistantes en un seul coup dans un contrôleur par example. Il ya mieux à faire pour avoir seulement un seul Dao, une seule instance pour toutes les classes persistantes.

[libuma]

J'ai dû adapter un peu mais ça fonctionne très bien merci!

Aussi, dans l'implémentation du manager, j'ai procédé comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public void loadClass(Class classBean) {
	this.classBean = classBean;
	myDao.loadClass(classBean);
}

Pour que le classBean du DAO soit automatiquement instancé.

Et dans le controlleur alors :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
	@Autowired
	@Qualifier("commonManager")
	private CommonManager<Satisfaction> commonManager;
 public ModelAndView handleRequest(HttpServletRequest arg0,
			HttpServletResponse arg1) throws Exception {
 
		ModelAndView modelAndView = new ModelAndView("newReport");
			commonManager.loadClass(Satisfaction.class);
		modelAndView.addObject("commonList",this.commonManager.getList());
 
		return modelAndView;
	}

Un grand merci !