comment structurer une modél. UML - projet J2EE avec pattern

Je suis entrain de modéliser un projet J2EE (Java server Faces, EJB 2.0 , Hibernate) et des patterns.

L'organisation actuelle en considérant les patterns J2EE (Business delegate, sessionFacade, et Servcie locator et autres) :

- couche EJB avec un découpage fonctionelles ( future fichier jar )
et chaque couche fonctionelle est découpé :
- facade :
a. client : Business delegate (sera déployé dans le war)
b. serveur : sessionFacade + Servcie locator (sera déployé dans le jar)
- persitance : classes hibernate
- service : metier
- vo : value objects
- couche WEB : jsp et pages web

avec un package pour les librairies.


est ce qu'il y a un découpage standard?
est ce que mon découpage est dans les normes ?
pouvez vous me proposer une autre organisation?

merci et a+

Ma recommandation est que ton découpage logique soit adapté à ton découpage physique en .jars, .wars, .ejbjars et .ear. Il est en effet important, lors d'une modification sur un package de pouvoir relivrer le strict minimum.
Il te faut donc au moins un découpage par couche. Pour chaque couche, je te conseille d'isoler les interfaces, au sens Java du terme mais aussi au sens "interface de package" = les Façades. Isoler les Business Delegate me parait aussi utile.
Ensuite, même au niveau de chaque couche ou "paquets" de Business Delegate ou paquets de façades, un découpage fonctionnel me parait nécessaire. Par exemple, pour la couche "objets du domaine", les objets a priori persitants, je te conseille de faire plusieurs .jar par domaines fonctionnels (par packages Java si tu as bien structuré ton arborescence).

Pour avoir une idée du découpage, regarde le découpage fait dans Hibernate ou SPRING ou dans le JDK !!

merci pour toute les explications.
je verai alors le découpage dans hibernate et struts..
merci beaucoup

Bonjour,

Topic dans mes préoccupations actuelles...

Quelle différence est faite ici entre la couche EJB et la couche service ?

Les VO sont-ils placés dans une couche à part ?

Les VO et les façades constituent-ils des couches de l'application ? Je voyais plus ces classes comme appartenant aux autres couches.

Qu'en pensez-vous ?

8)

Frédéric

En fait les VO vont transiter dans plusieurs couches.

Il n'y a pas en fait d'appartenance obligatoire des objets/classes à une couche précise. Cette appartenance est surtout vraie pour les objets de type "services" mais les objets de type "données" sont souvent manipulés par plusieurs couches.
Ce qu'il faut savoir c'est qui les créé ? Ensuite ils sont utilisés par plein d'autres objets. Il faut aussi bien les isoler dans des .jar spécifiques pour pouvoir facilement les déployer sur différents tiers physiques si besoin (et aussi c'est plus facile d'organiser le projet et le packaging).
Alors qui créé les VO ? Cela peut dépendre de ton appli. Ce peut être la couche d'accès aux données ou la couche "application" qui récupère des objets "complets" et fabrique, à partir de ces objets des VO spécifiques du service que ces objets rendent. Mais si tu as une approche très orientée "données", je pense que ta couche accès aux données se chargera de créer les VO.

Enfin, c'est ma vision....

Merci.

En fait, pas de règle à proprement parler. Je vais opter pour un package à part car ils sont créés dans les actions struts et manipulés par les EJB et les DAO. Finalement, je ne les vois pas dans la couche avec les actions et je vais donc les mettre à part. Ca sera plus clair pour l'architecture et plus simple pour le déploiement.

- une couche présentation (classes struts + classes business delegate)
- une couche métier (session façade + ejb)
- une couche données (dao)
- les vos (pas vraiment une couche n'est ce pas ?!)

A+, Fred

c'est très bien selon moi !

Extra, merci pour ta réponse :) ! Je doutais encore un tout petit peu mais j'ai fait la synthèse de plusieurs posts et de mon opinion pour en arriver à ce découpage.

Merci encore pour ton avis :D

Ego, je reviens sur une des phrases d'un post de ce fil. Les VO sont manipulés par plusieurs couches.

Cela signifie-t-il qu'on peut aller jusqu'à les utiliser dans la couche de présentation pour l'affichage ? Peuvent-ils être accédés par un taglib par exemple s'ils sont placés dans le scope request ?

Je délire ? :D ?

Les VO peuvent très bien (techniquement) étre utilisés dans l'interface. Pour pouvoir etre utiliser avec les tagLib, ils leurs suffit d'implementer correctement les getters et les setter de leurs attributs. :wink:

Oui, techniquement c'est possible mais :

1/ je ne sais pas si d'un point de vue d'architecture (isolation des couches précisément), ça ne pose pas de problème de laisser un taglib accéder des VOs, que je voyais davantage accédés par les EJB et les DAO. Cela reviendrait presque au même qu'afficher des attributs de VOs directement dans l'interface sans passer par l'ActionForm. Mais pê que je me contrains pour rien ?

2/ reste qu'il faut que le taglib fasse les conversions nécessaires pour transformer les types de données des VOs en String.

Frédéric

1. Pour moi ça ne pose pas de problème. Mais bon, j'ai bien remarqué que tu doutais... :wink:

2. Les tag font les conversion de tous objets implementant la méthode toString + des types primitifs (int, double...)

je suis d'accord à 100% avec viena
je ne vois pas où est le problème pour ftrifiro !
Ce qui est probable c'est que le modèle manipulé par le C et le V du MVC (le M donc), pourra être un agrégat de plusieurs VO. Les VO sont là justement pour répondre à des problématiques de manipulations partielles de l'information en fonction de différents contextes. Les VO peuvent donc complètement être créés pour des besoins spécifiques d'affichage !!!!

Pour le projet en cours, j'ai pris le parti de formater les VOs en String prêtes à l'affichage dans des objets standardisés. Ca fonctionne pas mal, c'est bien générique et ça gère nickel les listes à paginer.

Mais je retiens vos deux avis quant au fait que les VOs peuvent se balader partout dans l'appli.

A+, Fred

Le problème de la convertion des VO en String est justement le manque de typage que cela induit au niveau du V et C.
C'est un des problèmes que SPRING reproche à Struts par exemple = le non typage des informations manipulées.
Dans SPRING, tu ne travestis pas l'information, tu exposes tes objets tel que tu les as conçu et les types sont transportés jusqu'au niveau de la vue.
Je te conseille, si tu as du temps, de regarder la partie MVC de SPRING

Dans le cadre de ce projet, c'est mort. J'ai déjà eu toutes les peines du monde à justifier qqs jours de réflexion sur l'architecture avant de partir en dev 8O !

Par contre, j'ai l'impression que Spring fait partie des pistes à envisager sérieusement pour un prochain projet. Ca semble très prometteur. Après faut voir dans la pratique. C'est déjà utilisé dans les entreprises ?

C'est utilisé dans les entreprises.
En général un peu plus dans les entreprises tecnique car moins connu (car moins de pub, moins de partenaires...).
Cependant c'est de plus en plus utilisé. En fait, c'est dépend souvent des personnes qui influence les choix architecturaux...

SPRING est effectivement très utilisé sur de vrais projets en production. Je travaille dans la banque et certains projets l'utilisent.
SPRING est, sur ma déjà longue carrière, le framework le plus intéressant et le plus emballant que j'ai vu. Sa couverture et sa conception répond selon moi à énormément de très bons principes d'architecture et de conception.

Pour connaitre tout sur le papier peint il faut avoir lu Venilla. Pour avoir de solides bases en conception il faut avoir lu SPRING ! :)

Citation:

---

Envoyé par ftrifiro

Merci.

En fait, pas de règle à proprement parler. Je vais opter pour un package à part car ils sont créés dans les actions struts et manipulés par les EJB et les DAO. Finalement, je ne les vois pas dans la couche avec les actions et je vais donc les mettre à part. Ca sera plus clair pour l'architecture et plus simple pour le déploiement.

- une couche présentation (classes struts + classes business delegate)
- une couche métier (session façade + ejb)
- une couche données (dao)
- les vos (pas vraiment une couche n'est ce pas ?!)

A+, Fred

---

Je me permets de revenir sur ce post.
Dans la couche métier, que distingue les classes "Session Facade" des ejbs (partie en gras ci-dessus) ?
J'ai lu le pattern session facade sur le site de sun. J'ai vu qu'un session facade pouvait dialoguer avec plusieurs types de "Business Object" :

• Session Bean
• Entity Bean
• Dao

Je comprends pour les deux derniers points, mais pourquoi un "session bean" ? Que distingue le "Session Facade" du "Session Bean" ? Si je regarde le tuto disponible sur developpez, je ne vois pas cette relation.

Je vais prendre un exemple. Imaginons une gestion de facture. Sur une action utilisateur, j'ai le traitement suivant :

• Contrôle des droits de l'utilisateur
• Mise à jour de l'état par l'api de Workflow
• Envoi de mails

Faudrait-il le déroulement suivant :

1. Le business delagate appelle le session facade "FactureFacade"
2. Le FactureFacade appelle un session bean pour vérifier les droits
3. Le FactureFacade appelle un Session Bean pour la mise à jour de l'état
4. Le FactureFacade appelle un Session Bean pour l'envoi du mail

Merci d'éclairer ma lanterne. :)