Bonjour,
j'ai parcouru ce forum et malgré certain post intéressant, je ne trouve pas de solution au problème suivant. Pouvez vous m’aidez ?
Présentation de notre architecture :
Nous avons choisi de partir sur une architecture à 5 couches (Inspirée très fortement de celle de improve-foundations) qui est définie comme telle :
Couche « présentation » à Beans JSF et page JSF
Couches « application » et « entreprise » à Beans métier et Classes Service
Couche « ORM » à Beans et classe DAO
Couche « Persistance » à SGBD
Bien qu’elle soit très souple, cette architecture n’est pas sans poser certains problèmes.
Notre problème étant de garantir l’intégrité des données au travers de toutes ces couches.
Lors de l’affichage d’une page JSF nous n’avons pas trop de problème. Les pages JSF ont des composants qui pointent sur des attributs de nos beans JSF. Ceux-ci s’initialisent en demandant à la couche métier (via des services) de nous renvoyer un bean métier qui sert de source de données à nos beans JSF. Ces beans métiers sont eux-mêmes instanciés à partir d’un graphe d’objets VO récupéré via un appel de méthode des classes DAO (Appel réalisé dans une classe service).
Notre problème :
Lors d’une modification des données par l’utilisateur, les choses se compliquent... En effet, les données du formulaire JSF ne suffisent pas à remplir tous les champs de l’objet métier. Cet objet métier étant rempli partiellement, cela pose des problèmes pour remplir le graphe d’objet VO correspondant et ainsi persister les données saisies dans la page JSF.
(problème similaire sur l’intégrité des données MAIS inexploitable dans notre cas :
http://www.developpez.net/forums/sho....php?p=1583077 [FRANÇAIS])
Solutions possibles :
Pour garantir l’intégrité des données, nous avons trouvés plusieurs solutions, mais aucune n’est vraiment satisfaisante :
- Charger tout le graphe d’objet entre les couches.
La requête remontant le graphe VO est énorme et permet de mapper tous les champs du bean métier. Quelque soit l’écran JSF, on récupère tous les champs. Le lazy-loading sert à rien…
Gros inconvénient :
Performance très très dégradée, perte de souplesse
- Développement d’un objet métier ou graphe d’objet métier spécifique à chaque écran.
On se retrouve guidé par la base de données (domain driven developpement). Or notre base est héritée d’une application existante et pas du tout pensée pour notre nouveau projet.
Gros inconvénient :
Perte de la généricité
Multiplication du code, perte de qualité et maintenabilité
- Solution basée sur un outil de peuplement tel Dozer ou JAXB.
On a aucune idée de l’implémentation correcte de cette solution.
- Enlever la couche métier
Gros inconvénient :
Perte de souplesse et d ‘évolutivité
Contre les recommandation d’application complexe (WebServices)
En fait, nous avons pensé à beaucoup plus de solutions et nous avons fait plus de recherches que ce qui est présenté juste au dessus. Néanmoins nous essayons d’être le plus synthétique possible et espérons apporter plus de détails au travers d’un dialogue.
Nous vous remercions d’avance.
Partager