[Design] Séparation des couches

Bonjour à tous,

Je me suis longtemps questionné sur le design (séparation des couches) d'une appli J2EE.
Et en cherchant sur le forum je suis tombé sur bcp de messages, qui expliquaient les notions DAO, VO / DTO et les classes Businness associées au VO (value Object).
J'ai souvent pratiquer de la sorte, sans connaitre la définitions de toutes ces notions ( et j'en suis pas encore sur pour certaine).

Mais je m'interroge encore sur cette facon de faire, car si mon objet VO par exemple : unEmployé à besoin de me retourner tout le cumul de ses salaires. Je serai tenter d'ecrire quelque chose de la sorte :

unEmployé.getCumulSalarial();

Ma méthode getCumulSalarial() contient donc de la logique métier et en plus elle va surement faire un access à la base de données. Donc la je pert toute l'indépendance des couches en faisant ca !!

Alors a moins d'ecrire un objet business et de lui implementer la méthode demander : employéBusiness.getCumulSalarial( unEmployé.getID() ) Je ne vois pas comment faire !!!!

Je trouve ca tellement plus parlant de faire unEmployé.getCumulSalarial() surtout qu'on peut mettre en cache l'information (au premier appel de la méthode ) dans l'objet pour éviter de faire tout le tps des appels BD. Mais ca boulverse complemetement la notion que j'avais de séparation des couches !!!

Quelqu'un pourrait éclairer mes lanternes sur ce point ?

Merci par avance

Premièrement la séparation des couches ne veut pas dire qu'une couche n'a pas le droit d'en appeler une autre où sinon, je ne vois pas comment faire tourner un logiciel !!
Pour ton cas qui consiste à se demander s'il faut donner de l'intelligence à un VO, je dirai que ce n'ai pas l'objectif ud pattern VO.
Avec ce genre de pattern, tu es plus dans une approche de type données-traitements où les données sont les VO et les traitements sont assurées par des classes de type "services".

Tu peux lire ceci http://ego.developpez.com/uml/tutori...esTraitements/ pour mieux comprendre mon point de vue.

Merci Ego de me repondre ( une fois de plus)

Je n'ai aucunement penser que mes couches ne pouvaient pas s'appeller entre elle, je me suis peut etre mal exprimé.

Tu me dis que je suis dans un cas ou je sépare les traitements des données, mais alors si ce n'est pas le seul type d'implémentation possible pour séparer la logique business des données je ne voient pas du tout comment faire autrement pour implémenter un design en trois couches ( data, business, présentation).

Je viens de lire ton article ( que j'avais déja lu il y a quelque temps) mais si on ne sépare pas la couche donnée et traitement, alors qu'est ce qu'on appel donc la couche Business ????

Et dans le cas ou je ne séparerais pas les données du traitement comment j'implementerai ma méthode getCumulSalaire() , il faudrait que j'accede directement a ma couche DAO ou mettre du code SQL dans mon objet Salarié ??

La couche Business contient en fait les données et les traitements dits "métier". C'est à dire les données et traitements jugés intrinsèques au métier et non dépendant de l'usage qui peut en être fait par une application ou une autre.
Ensuite, dans cette couche, tu as des traitements qui peuvent être supportés par les objets données et/ou par des objets "pur" traitements. A toi de voir qu'elle est la meilleure solution en termes d'attribution des responsabilités, en terme d'évolution, en terme de distribution,...

L'objet "Salarie" peut avoir une opération "getCumulSalaire". Cet objet est retourné par ta couche DAO (ex : SalarieManager.findByName("jean dupond")). Pour le calcul du cumul, je ne sais pas comment cela fonctionne dans ton logiciel, cela pourrait être directement codé dans la méthode getCumulSalaire si le cumul repose sur une liste d'objets associés à Salarie (pas de requête SQL a priori dans la classe Salarie) ou bien la classe Salarie peut faire appel au DAO qui lui fait la requête SQL appropriée ex :

Code:

---

getCumlSalaire() { return SalarieManager.cumulSalaire(); }

---

Alors la Ego tu chamboules tout dans ma tete , mais c comme ca qu'on apprend, j'ai longtemps cru que les VO faisaient partie de la couche de présentation, donc que mon objet Salarié était une composante ce cette couche et que tout ces traitement spécifique était déléguer a une autre couche que l'on appellait bisness.

Maintenant si je comprend bien, Salarié fait aussi partie de la couche bisness tout comme ses traitements d'ailleur !!!!

Pour le moment je n'ai pas d'application, donc on peut dériver au maximum les méthodes de calcul du cumulSalaire, j'ai juste pris ca pour exemple pour mieux comprendre. :lol:

Par contre j'ai vu dans un applicatoin qui tournait un objet (toujours par ex) Salarié, avec une méthode Save() dessus qui lui permettait de se sauvegarder en base de données !! Je trouvais ca completement anarchique en terme de Design mais finallement en te lisant je me dit que c'est pas si mauvais que ca ?

Les VO ne sont pas nécessaire la "propriété" d'une couche. Tout dépend de pourquoi tu les as créé.
Sinon, il y a des objets qui sont transverses aux couches comme certaines données.

J'utilisais les VO et les Services car pour moi ca voulait dire faire une disctinction NET entre la presentation et le métier........... apparement j'avait tout faux !!! :lol:

donc ce que tu m'as donner comme exemple :

getCumlSalaire() { return SalarieManager.cumulSalaire(); }

n'a rien de choquant et c'est tout a fait "design" ?

Aurais tu un/des liens, ou des bouts de codes avec des exemples parlant qui séparent bien toutes ces couches (genre une mini application toute simple avec un peu de logique métier ) ?

Attention, je n'ai pas dit que les VO ne sont pas liés à la couche présentation. J'ai seulement dit que cela dépend de ton intention quand tu les as créé.
Si tu as créé les VO exclusivement pour faire de l'affichage alors cela à un sens de les associer à ta couche présentation. Le problème avec ces patterns et que tu te retrouves vite avec des objets"métier" persitants - Salarie et des VO correspondant - SalarieVO (ok, ce n'est pas exactement ton exemple mais c'est pour t'expliquer le truc). Jusque l'a, pas trop de problème. Mais cela devient carrément chi..t quand tes objets ont des relations avec d'autres objets. Tu as alors un modèle objet avec des associations (référence ou collection de références) et le "même" modèle côté VO = des VO en relation. Cela te fait vite 2 modèles parallèles à gérer. Et c'est vraiment la galère.
Le "mieux" (là c'est juste mon avis) c'est de n'avoir qu'un seul modèle objet. Et donc pour ne pas trimballer des classes trop grosses, mon modèle d'objets persitants ressemble assez à un modèle de données classique type entités-relations (des VO en relation). Les traitements supportés par ces données sont assez faibles et ne sont vraiment que les traitements jugés intrinsèques. Les autres traitements sont dans des classes "traitements".
Cela fait très séparation données - traitements mais c'est pas grave !!!

Finallement je comprend qu'il n'y a pas de méthodes imposées, mais plutot des méthodes conseillés, comme celle que tu préconises Ego.

Selon ce que tu exposes Ego, je me pose quand meme une question :

1/ Comment assure tu la persistances des relations a un objet, je m'explique si tu as un obj Commande il possedent probalement une collection d'Item. Pour divers raison dans l'application tu n'a pas forcement besoin de ces items mais juste de l'entete de commande ( numéro, montant, nom, prenom...). Je suppose donc que tu dois passer par un Service qui possede une méthode du genre LoadCommande() !! Or dans certain cas tu veux les items et dans d'autre pas !!! Comment fais tu pour distinguers les traitements avec et sans Item. Si tu as une méthode getItem() sur une classe de Service, alors on ne manipule plus dans ce cas Commande.items mais simplement une collection d'Item indépendant de la classe Commande. :roll:

Ce que tu mentionnes est résolu par le "lazy loading" des collections, voir des attributs.
Avec un framework comme Hibernate (mais c'est le cas d'autres frameworks), tu peux lui demander de faire du lazy loading. C'est à dire que lors du chargement de la Commande, les Items associés ne sont pas chargés. Ils le seront au premier appel à la collection des Items de la Commande. Il y a aussi des fonctionnalités de "fetch" dans le langage de requête HQL qui permet de demander des chargements qui n'auraient pas été fait avec le lazy loading.
Bref, en déclarant tes objets persistants comme Serializable, tu peux alors transporter une grappe d'objets d'un tier à l'autre sans te faire chi... avec les VO.

Citation:

---

Envoyé par ego

C'est à dire que lors du chargement de la Commande, les Items associés ne sont pas chargés. Ils le seront au premier appel à la collection des Items de la Commande.

---

Si je n'utilise pas hibernate ou autre je suis donc obliger de passer par une methode de mon objet metier (Commande) qui appelle une methode de l'objet Service associé a la commande.

soit : dans la méthode getItem de l'objet Commande

getItem() {
if ( this.item == null) {
this.item = ServiceCommande.getItem(this.id)
}
return item
}

Citation:

---

Bref, en déclarant tes objets persistants comme Serializable, tu peux alors transporter une grappe d'objets d'un tier à l'autre sans te faire chi... avec les VO.

---

La j'ai pas bien compris mais je vais essayer de me documenter la dessus !!!

En tout cas merci Ego pour ta patience :?

ok pour getItem.

Pour le passage entre tier, je veux dire que les protocoles comme RMI attendent que les paramètres des "services" distribués soient "Serializable" (interface Java du JDK) pour pouvoir être passés "dans le tuyau". Donc en créant des objets Java "simples", les anglais disent des POJO, et avec le lazy-loading, tu as ce qu'il te faut pour faire passer tout ou partie d'un graphe d'objets du serveur au client (dans le cas où le client n'est pas sur la même machine que le serveur).

Merci Ego pour toute ces explications :D

Je ferme ce thread, et je vais essayer de comprendre l'architecture du petStore de Sun pour aller plus loin !!!! :!:

<tousse>

Je ne suis pas sur que petStore soit un choix judicieux...
Cette application est un simple exercice de style mettant en avant 1000 concepts n'ayant aucune justification dans l'application elle-même.

Tu risque de t'y perdre plus qu'autre chose...

Une bonne lecture : SPRING (www.springframework.org)

Merci Alwin ........ de me retenir avant le grand saut !!!!

Spring, j'hesite a m'y plonger car je ne connais pas encore Struts et quand je regarde les demandes du marché elles parlent toutes de Struts !!!

Si ton intéret porte sur les architectures en couche, fonce sur Spring...
Struts n'est qu'une implémentation d'une couche cliente web

Comme je vois que tu est très curieux, je te conseil de regarder les architectures orientées services (AOS ou SOA en anglais).
C'est une vision "non orientée" application des architectures en couches.

Ok alors je vais regarder ca !!!
merci a vous deux de vos conseils, faut vite que je quitte le monde VB !! :lol: :lol: