Discussion :

[trax020]

Bonjour à tous,
Je voudrais développer une application Web avec Struts, Hibernate et Spring. Je souhaiterais savoir comment structurer mes packages java, j'entends par cela: les business objects(les beans représentants les tables relationnelles?), les dao(CRUD sur les beans), les services(la logique metiers c'est ca?), les classes action et actionform de Struts(logique applicative?).
Je voudrais également une confirmations quant au termes cités entre parenthèses...
en supposant que le package de base est com.compagny, comment organiser les packages? Merci d'avance

[dlemoing]

Pour ma part, je pense que la logique métier doit se trouver dans les objets métiers (ce n'est pas juste une bete représentation de la base).
La logique applicative comme tu la nommes doit être dans les services (ou dans les objets métiers). Les actions Struts se contentent d'utiliser les services (pas de métier) pour récupérer un model qui sera utilisé dans la vue.

En résumé :
- objets métiers : données et comportement métier
- dao : CRUD
- services : contiennent un minimum de logique (souvent nommée logique applicative) et organisent un workflow (chargement des objets métiers, appel de la logique métier dans les objets métiers, ...)
- controlleur (C de MVC) : appel sur la couche logique (souvent des services) pour récupérer un model que la vue se chargera de présenter.

[trax020]

Oh la laaaaaa j'etais complètement out
Donc, si j'ai bien compris, si par exemple j'ai un une table Employe ayant pour champs matricule, nom, prenom et salaire, je dois avoir les éléments suivants:
DAO

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
 
public class EmployeDao{
public void createEmploye(Employe e){
....
}
public void readEmploye(int matricule){
....
}
public void updateEmploye(Employe e){
....
}
public void deleteEmploye(int matricule){
....
}
 
}

Objet metier

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 Employe{
private int matricule;
private String nom;
private String prenom;
private float salaire;
/*
*les getter setter
*/
 
public void augmenterEmploye(float montant){
this.setSalaire(this.getSalaire()+montant);
DaoEmploye dao=new DaoEmploye();
dao.updateEmploye(this);
}
 
 
}

ET au niveau des actions de struts faire un appel a la methode augmenterEmploye.
En gros c ca? ou suis je suis encore passé à coté de la plaque
Si possible m'indiquer un lien avec des exemples concrets et merci

[dlemoing]

Tu n'étais pas totalement out et je ne t'ai donné qu'un point de vue. Par contre, le code que tu présentes introduis un gros problème, la relation entre tes objets métiers et les autres couches.
Voici quelques regles à respecter :
- ton objet métier ne doit pas avoir de dépendances avec aucune couche (pas de lien avec le dao comme tu l'as fait)
- ta couche persistance (dao), a une dépendance vers tes objets métiers (et la technologie sous-jacente : ORM, JDBC, ...)
- ta couche service a une dépendance vers tes objets métiers (appel de méthode métier) et vers tes DAO (chargement, update des objets métiers)
- ton controleur a une dépendance vers tes services (appel pour enclencher le traitement métier) et vers tes objets métiers (pour former le model qui sera représenté dans la vue).

Pour des exemples concrets et comme tu souhaites utiliser Spring, regarde les exemples qui sont fournis avec la distribution.

[FreshVic]

Salut,
Personnellement je fais des objet de données metier qui comme le nom l'indique ne contienne que des données et aucun traitement , ensuite tu as les service metier qui serons susceptible de fournir des service metier a plusieurs applications (couche entreprise) puis une couche application traitement propre a l'application , puis la couche presentation (Struts) il faut un minimum de code dans tes action uniquement de l'initialisation des ActionForm et appelle a des objets de la couche inferieur (Application)
Enfin bref cet article t'en parleras meiux que moi :
http://www.application-servers.com/articles/multicouches/index.1_0.html

[viena]

Tu n'étais pas totalement out et je ne t'ai donné qu'un point de vue.

Puisque moi je dirais que les beans et la logique métier doivent être séparés... Les beans sont voués à être transportés et ça ne sert à rien de les alourdir...
Mais bon, ça depend beaucoup de ce que tu veux faire. Moi je travaille avec d'enormes traitements, et comme je n'aime pas avoir d'enormes classes, je préfére séparer les différentes couches.

[dlemoing]

Tu n'étais pas totalement out et je ne t'ai donné qu'un point de vue.

Puisque moi je dirais que les beans et la logique métier doivent être séparés...

Pourquoi devrait on séparer les données et le comportement ? Quel est la définition d'un objet ? Pourquoi devrait on ignorer toutes les bonnes pratiques objets quand on fait du J2EE ?

Les beans sont voués à être transportés et ça ne sert à rien de les alourdir...

Quand tu parles de transport, tu parles de distribution ? Si c'est le problème, la solution a un nom : DTO (Data Transfer Object). Cela consiste à former un objet sérialisable à partir de tes objets métiers dans le but de le distribuer. Cet objet n'a pas de comportement métier, il contient juste des données.

Mais bon, ça depend beaucoup de ce que tu veux faire. Moi je travaille avec d'enormes traitements, et comme je n'aime pas avoir d'enormes classes, je préfére séparer les différentes couches.

Pourquoi dis tu que je ne sépare pas les couches ? Il me semble au contraire que je définis exactement le role de chacune de mes couches et qu'elles ont toutes une responsabilité bien définie.
En ce qui concerne les traitements, un certain nombre de patterns peuvent être employés pour ne pas surcharger les classes (strategy, state, ...). De plus, une bonne conception doit permettre de se passer des if/else que l'on retrouve très souvent quand la logique est implémentée sous forme de transaction script dans les services (ca sent le procédural tout ca, pas très objet).

[dlemoing]

Un lien pour appuyer ce que j'écris : http://www.martinfowler.com/bliki/AnemicDomainModel.html
Je vous conseille la lecture de son livre Patterns of Enterprise Application Architecture.

One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer. But this isn't an argument to make the domain model void of behavior, indeed service layer advocates use a service layer in conjunction with a behaviorally rich domain model.

C'est plus ou moins ce que je dis ici :

- ta couche service a une dépendance vers tes objets métiers (appel de méthode métier) et vers tes DAO (chargement, update des objets métiers)

[alexismp]

D'un point de vue structuration:
http://java.sun.com/blueprints/code/...nventions.html

[trax020]

Merci à tous pour ces points de vue. C'est très enrichissant.