[Strategie]Classes de mapping & Objets métier

Bonjour;

Lorsqu'on fait du mapping O/R via un framework (Castor ou hibernate), est il nécessaire de différencier les classes de mapping avec les classes d'objets métiers (OM).
Par exemple : j'ai une classe d'OM "personne" avec ses attributs (nom, prénom, ...) plus ses services (méthodes CRUD + la recherche).
La couche de mapping génére une classe de mapping DBPersonne avec les accesseurs (get/set) + ID + attributs.

Autre Q : ce n'est pas lourd et redondant ? car on a pratiquement les même classes à qcq points de différences.
Si vous avez une autre approche, je serais très interessé.

Merci;



[Modéré par Didier]
Ajout de balises code pour la lisibilité
Lire les règles du forum : Règles du forum Java

Moi je préfére séparer les objets de leur métier.
J'ai donc des Objets de type "bean" (attributs + getter/setter) utilisés pour le mapping et pour le stockage des info. et des classes métier pour les fonctionnalités de l'appli, qui utilisent des méthodes (CRUD et recherche) de classes d'accès aux données.

Citation:

---

Envoyé par viena

Moi je préfére séparer les objets de leur métier.
J'ai donc des Objets de type "bean" (attributs + getter/setter) utilisés pour le mapping et pour le stockage des info. et des classes métier pour les fonctionnalités de l'appli, qui utilisent des méthodes (CRUD et recherche) de classes d'accès aux données.

---

Hormis la modularité du code, quel est l'interêt de cette approche ?

A+;

la possibilité de générer les classes de mapping (avec des script, une interface graphique ou autre) sans ecraser du joli code metier par exemple.

Citation:

---

Envoyé par lunatix

la possibilité de générer les classes de mapping (avec des script, une interface graphique ou autre) sans ecraser du joli code metier par exemple.

---

Autre question : au niveau de la couche OM, est ce que tu sépare également les services d'un OM (CRUD + find) et l'objet lui même.
Par exemple :

Classe Personne sera séparée en 2 classes :

1- Personne (attributs + get seulement)
2- Pesronne service (toutes les services : CRUD + la recherche)

A+;

Oui.
En fait, le principe, c'est d'avoir une bonne séparation des couches (accès base, métier, interface), qui permet, entre autre, de faire des modif', même très importante, dans une couche, sans impacter les autres (la bonne solution est donc d'utiliser des interface pour relier les différentes couches.
Et d'avoir des Objets, sorte de DTO (et même carrement DTO, lol), qui permettent de faire circuler les données entre les couches, qui effectuent les traitements par rapport aux données contenues dans le DTO.

Citation:

---

Envoyé par viena

Oui.
En fait, le principe, c'est d'avoir une bonne séparation des couches (accès base, métier, interface), qui permet, entre autre, de faire des modif', même très importante, dans une couche, sans impacter les autres (la bonne solution est donc d'utiliser des interface pour relier les différentes couches.
Et d'avoir des Objets, sorte de DTO (et même carrement DTO, lol), qui permettent de faire circuler les données entre les couches, qui effectuent les traitements par rapport aux données contenues dans le DTO.

---

OK : tu peux me donner un exemple simple ou une adresse ?

A+;

Bean :
PersonneBean : classe de transfert de données. Elle contient les attributs et les getters et les setters. Ces derniers peuvent être évolués selon le besoin (getTelInt, getTelString -> attention, dans les jsp, il faudra utiliser les attributs telInt et telString dans les tag pour que ca fonctionne!)

Base :
PersonneDAO, classe d'accès aux données contenant les méthodes CRUD et get, ou autres méthodes utiles, pour les méthodes de modif de base, on lui passe un objet PersonneBean contenant les info nécessaires et pour les méthodes de recup' de base, on recupere un objet (ou une liste d'objets) PersonneBean, qu'on créera grace aux resultats (ou qui se "créera tout seul" grace au mapping).

Metier :
PersonneBusiness : classe de métier, qui effectue les calcul s'il y en a... enfin bref, le métier quoi.
Le métier peut être orienté vers les classes DAO (comme précédemment), et donc implementer des méthodes propres aux objets ou orienté fonctionnel et donc implementer des méthodes propre aux fonctionnalités (rechercherPersonneConnectée)

Action -> JSP : pour moi, les actions sont liées aux JSP et donc aux fonctionnalités que tu dois mettre en place. Elles vont effectuer les validation, la mise en forme des données si besoin, appeler le métier, récupérer les DTO (bean) et les envoyer à la JSP.

Citation:

---

Envoyé par viena

Bean :
PersonneBean : classe de transfert de données. Elle contient les attributs et les getters et les setters. Ces derniers peuvent être évolués selon le besoin (getTelInt, getTelString -> attention, dans les jsp, il faudra utiliser les attributs telInt et telString dans les tag pour que ca fonctionne!)

Base :
PersonneDAO, classe d'accès aux données contenant les méthodes CRUD et get, ou autres méthodes utiles, pour les méthodes de modif de base, on lui passe un objet PersonneBean contenant les info nécessaires et pour les méthodes de recup' de base, on recupere un objet (ou une liste d'objets) PersonneBean, qu'on créera grace aux resultats (ou qui se "créera tout seul" grace au mapping).

Metier :
PersonneBusiness : classe de métier, qui effectue les calcul s'il y en a... enfin bref, le métier quoi.
Le métier peut être orienté vers les classes DAO (comme précédemment), et donc implementer des méthodes propres aux objets ou orienté fonctionnel et donc implementer des méthodes propre aux fonctionnalités (rechercherPersonneConnectée)

Action -> JSP : pour moi, les actions sont liées aux JSP et donc aux fonctionnalités que tu dois mettre en place. Elles vont effectuer les validation, la mise en forme des données si besoin, appeler le métier, récupérer les DTO (bean) et les envoyer à la JSP.

---

Bonjour;

OK : tu sais ou je peux trouver des exemples d'implémentation java/j2ee avec cette même approche multi-couches ?
Juste pour voir comment les objets communiqueent entre eux via ces couches.

Merci;

il y a un super article la
http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html

et le war est ici
http://www.javaworld.com/javaworld/jw-07-2004/jsf/jw-0719-jsf.zip

C'est une applic basée sur un model en couche.
donc un bean pour l'affichage,
des services métiers,
des DAO
et des VO (value object).

le toute isolé par des interfaces...

Cet exemple utilise Spring pour le métier, hibernate pour la persistance,
mysql comme db, et le pool de connection de apache. le GUI utilise lui JSF,

il y a même les fichiers SQL pour créer la base et les données de test

A+

Je vais peut etre dire une betise mais si on fait herité la classe metier de la classe transfert on evite les redondance et la duplication du code .
En fait j'avourais que je voix pas du tout l'utilité des DTO si quelqu'un peut m'eclairer !!
Le traitement metier a besoins des données metier alors pourquoi ne pas vouloir les regrouper dans une meme classe ???

Pardon si je dis des enormités

si on a une structure du style :

1 table -> 1VO (get et set) -> 1 dao (CRUD + find)-> 1 service -> 1 ecran

effectivement, il me semble que cela ne sert pas a grand chose, pire, il y a de la redondance.

Par contre, il y a des cas ou 1 écran regroupe plusieurs fonctionalités
par exemple, afficher une personne et son adresse.

Dans ce cas, un design possible est d'avoir un objet pour les adresses et
un objet pour les personnes. c'est la que les VO et les bean peuvent
être différents pour que le bean soit une façade sur plusieur properties de différents VO.

par ex :

1 table presonne->1 vo personne\
1 table adresse -> 1 vo adresse / -- 1 Doa (query avec jointure) > ...

... -> 1 service -> 1 bean ecran


le vo pour les personne a par ex. une meth. getNom()
le vo adresse une meth. petRue ()
le bean ecran a les deux méthodes et est une sorte de façade
pour le developeur en charge de l'écran.

le bean sert donc pour moi aussi à faire le mapping entre les champs de l'application et les VO (ou les tables si on veut).
Maintenant, si les champs de ton écran sont les mêmes que les champs de la table db, ça ne sert plus a grand chose à mon avis.


A+

Si tu mets les informations de ton objet (bean) dans ta classe metier, alors il faut passer ta classe à la JSP pour récupérer les info... un peu lourd de passer tout un metier pour cela!
un DTO permet de ne transporter QUE les informations nécessaires d'une couche à une autre. De plus, de cette façon, les couches sont indépendantes, elles ne communiquent les unes avec les autres qu'avec des DTO et s'il y a un changement technique dans une couche, ca n'impacte pas les autres.

D'accord donc l'equivalent du DTO ou VO c le beanForm dans struts (ActionForm) mais j'avoue que moi j'hesite pas a mettre des objets metier en attribut de mon formes de toute façon ils ont ete charger alors effectivement il occuperons de l'espace memoire ! apres cela depend du nombre d'objet a chargé si il y en a bcp vo surment mieux passer par un bean avec uniquement les info a afficher sinon tanpis :)
Je dis ca parce que d'apres se que dis viena on pourrais comprendre que passer un bean a la JSP c le faire passer via le reseau ce qui dans les deux trois projets J2EE sur lesquels j'ai travailler n'a jamais ete le cas !! (d'ailleurs je vois mal comment cela pourrais etre possible puisque la session et la requte serais different en passant sur un autre serveur )
Donc d'apres moi la seule 'lourdeur ' serait l'occupation memoire non???

Hello,

Citation:

---

Envoyé par FreshVic

Je dis ca parce que d'apres se que dis viena on pourrais comprendre que passer un bean a la JSP c le faire passer via le reseau ce qui dans les deux trois projets J2EE sur lesquels j'ai travailler n'a jamais ete le cas !!

---

Imagine : Tu as un serveur Tomcat qui tourne sur une machine et un serveur de persitence qui tourne sur UNE AUTRE machine... Les beans retournés par ton serveur de persistances passeront par le réseau, de plus ils doivent donc être sérialisables (doivent donc implémenter Serializable)...

Donc je suis favorable à pas de métier dans les beans...
@+

Et puis, je me répéte, mais pour la séparation des couches, les DTO c'est utile, et c'est quand meme plus propre.
Il faut penser aussi à la reutilisation du code et à sa maintenance (donc à sa compréhension).
Sinon, pourquoi ne pas tout faire dans une meme classe ??

D'accord je comprend mieux l'utilité d'un dto pour limité la dependance d'une couche a une autre et donc la reutilisabilité mais sur l'un des projets sur lesqels j'ai travailler on a commencer par utiliser des DTO avec un BeanUtils.copyproperties (introspection=lenteur) entre le bean metier et le dto (puisque ct les meme) au final on les a virés et on a gagné en temps d'execution et en temps de dev . d'autant plus qu'on etait sur de la non reutilisabilité d'aucune des couche (ce qui semble logique pour la couche vue et controlleur ) .

C parce que quand vous accédiez à la base, vous remplissiez un bean metier.
Moi, mon metier ne contient que des methodes. ce sont les beans qui contiennent les info. Ce sont eux qui vont etre chargés des info de la base. Donc pas de copyproperty.
Il s'agit juste de séparer le bean metier et 2 pour avoir une couche metier et un DTO.

Citation:

---

Envoyé par viena

C parce que quand vous accédiez à la base, vous remplissiez un bean metier.
Moi, mon metier ne contient que des methodes. ce sont les beans qui contiennent les info. Ce sont eux qui vont etre chargés des info de la base. Donc pas de copyproperty.
Il s'agit juste de séparer le bean metier et 2 pour avoir une couche metier et un DTO.

---

Bonjour;

Je voulais revenir sur ce sujet pour clarifier le pb suivant :
Lorsqu'on a une application j2ee de type n-tiers avec les couches classiques : couche présentation, service, métiers(objets persistants), et dao.
Il y'a souvent une confusion au niveau de l'implémentation des régles métiers : faut'il les mettrent
en amont ds l'ihm via du javascript (client léger) puis au niveau de la couche métier ou bien via des triggers ds la database ?
Si c'est au niveau de l'ihm : jusqu'au où l'on peux aller avec du javascript ou bien y'a t'il d'autre moyen pour un client léger ?
Exemple :
R1 : situation familliale (Célibataire, Mariée, Séparée, Dicvorvée), lorsque l'on choisit un élément,
la valeur de l'attribut "régime matrimoniale" est actif/inactif (booléan).
R2 : lors de mouvement d'un compte, si le crédit < 400 euros, pas de débit.
etc...

En vous remerciant

http://www.developpez.net/forums/vie...light=#1905276

le javascript c bien pour éviter au client certzines erreurs de frappes ou pour lui éviter des désagrement cô retaper un formulaire: meme si c utile, ce n'est pas indispensable et surtout il ne remplace pas tes regles de gestion coté serveur.
D'ailleurs, la vpc en ligne en a fait les frais au tout début, pouisque l'on pouvait contourner les scripts clients en construisant soit meme sa requete: sans regles de gestion coté serveur, les résultats étaient directement inscrits dans la bd...

Pour les trigers, c surtout pour délencher des trt propres à ta bd/schéma, independament et après validation du code métier (serveur)

Typiquement R1 --> coté client (mais n'empeche pas une vérification coté serveur)
R2 --> coté serveur