Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Architecture d'application web
Je suis entrain de developper une application en J2EE et j'ai des problemes a propos de l'architecture, j'ai utilisé celci :
Couche Web <--- DTO ---> Couche Metier <--- BO ---> Couche DAO
Je me demande si cette architecture est correcte ?
Si vous connaissez un exemple qui implémente cette architecture ou celle que vous pensez correct je suis pronneur.
Merci d'avance.
Je penses que la distinction DTO - BO n'est pas nécessaire.
Tu peux simplement faire :
WEB LAYER <-- dto --> BIZ LAYER <-- dto --> DAO LAYER
En effet, les DTO (Data Transfer Object) sont, par définition, des objets destinés au transfert de données entre couches.
Cette architecture offre une très bonne séparation des problèmes (je ne sais pas s'il en existe une meilleure).
Je pense que la plupart des applications web respectent cette architecture.
Donc vous pensez que je dois faire la transformation BO <-> DTO au niveau de la couche DAO, du fait que j'utilise Hibernate est je suis obligé d'utiliser les BO ?
Bonjour.
Peux tu s'il te plaît expliquer pourquoi un simple DTO ne te suffit du moment que tu utilises Hibernate ? Même dans les EJBs il est possible d'utiliser des simples POJOs comme DTOs avec JPA ...
Non, ce n'est pas ça que je veux dire.
Dans l'architecture que tu présentes, tu établis une distinction DTO - BO.
Or, comme j'en ai déjà fais l'expérience en pratique, il n'y a pas vraiment de différence entre un DTO et un BO.
La plupart du temps, les objets retournés par ta couche DAO seront utilisés tel quels par ta couche métier et ta couche web.
A titre d'exemple, considérons une classe 'Chien'.
Dans ton DAO, suppose que tu aies une méthode 'getChien(...)' qui te retourne une instance de la classe 'Chien'.
Suppose qu'un utilisateur désire afficher le chien qui s'appelle Médor.
Ta couche web va appeler la méthode 'getChien(...)' de ta couche métier.
Ta couche métier va appeler la méthode 'getChien(...)' de ta couche DAO.
Ta couche DAO va retourner une instance de la classe 'Chien'.
Ta couche métier va retourner cette même instance de la classe 'Chien'.
Ta couche web recevra cette instance de la classe 'Chien' et l'affichera à l'utilisateur.
Dans cette exemple, tu vois bien que tu n'as pas besoin d'une classe ChienBO et d'une classe ChienDTO.
Autrement dit, aucune transformation BO <-> DTO n'est nécessaire (puisque ce sont les mêmes objets).
Je pense que BO et DTO ne sont que deux noms différents, utilisés dans des contextes différents, mais qui désignent en réalité la même chose.
J'ai déjà utilisé Hibernate et il ne nécessite pas d'utiliser des objets particuliers (juste des beans Java).
Qu'entends-tu par BO et par DTO ?
Désolé si j'ai envoyé plusieurs copie de mon message cela est du à un probleme dans mon OS.
donc j'avais un petit probleme de nomination pour les BO.
Donc si j'ai bien compris:
Au niveau d'hibernate j'utilise des Beans, ensuite je les transforme en DTO dans la couche DAO.
Pour faire simple : un bean Java est un objet Java avec des attributs privés et des getters/setters pour ces attributs.
Via ta couche DAO, tu peux charger/insérer/mettre à jour/supprimer des beans dans ta DB.
Dans ton cas, ta couche DAO est supportée par Hibernate, ce qui n'impacte en rien le type d'objets à utiliser (ce sont toujours des beans Java).
Les beans Java manipulés par ta couche DAO peuvent être utilisés tel quels pour transférer des données entre les couches de ton application.
Aucune conversion n'est donc nécessaire (ce que tu appelles BO et DTO sont en fait les mêmes objets!).
Et bien tes DAOs sont justement batis juste au dessus d'Hibernate : Hibernate travaille sur les POJOs, de même pour tes DAOs. les unités de communications sont les DTOs qui eux sont des POJOs.
Bref, il existe déjà de nombreux posts sur ce thème, je te propose celui ci :
http://www.developpez.net/forums/sho...d.php?t=341618.
Il traite de Struts, mais l'idée est là !
Bonne chance.
Essayons d'aller pas à pas, et je suis désolé si je vous dérranges :
Hibernate récupére les données a partir de BD via des beans (POJO), ces meme instance je ne doit pas les laisser propager jusqu'a la couche metier (c'est pas trés sécurisé du fait que hibernate les surveilles) donc je doit faire une transformation vers des DTO au niveau de la couche DAO.
Bon je ne vais pas m'interesser a ce probleme de sécurité dans la 1ere itération.
Merci
Bonjour,
je n'ai pas la science infuse, mais personnelement je préfère distinguer DTO/Bean dans mon architecture. J'ai tenté de l'expliqué dans mon projet gestcv
DTO/Bean est un sujet sans fin car personne n'est d'accord. Moi ce que j'ai l'habitude de faire, c'est d'avoir une couche DAO qui gère des Beans (persistents). cette couche ne fait aucune agression d'autres Beans et ca n'est pas elle qui transforme les Beans en DTO. La construction de la DTO
se fait dans la couche service qui fait appels à plusieurs DAO. La couche service construit une DTO à partir de plusieurs Beans.
Ceci permet de :
- s'abstraire des problématiques de persistences des Beans. En effet Hibernate surveille les Beans qui ont ete récupéré par la session. Les objets qui doivent etre utilisés dans la partie présentation ne doivent plus etre persistents (je n'aime pas la notion de Filter qui gere la session Hibernate).
Si on veut passer le Bean directement a la couche presentation, on doit detacher absoluement l'objet.- d'éviter d'avoir un trop fort couplage avec la structure de la base de données. Hibernate permet de mapper des graphes d'objets Beans complexes. mais si on utilise directement le Bean dans la couche presentation, je trouve que l'on cree un fort couplage avec la structure de la base de données. Si ola structure de la base de données change, le Bean doit changer, ce qui impacte aussi la couche presentation/modèle (ActionForm, JSP,...). Si on utilise les DTO, seul la couche service est impactée.
Mais il est cepandant crai que les Beans et DTO se ressemblent tres fortement. Mais dans certain cas, ca ne suit aps cette règle. Par contre il est très rébarbatif de creer la classe Assembleur (ou autres choses) qui permettent de transformer un Bean en DTO et inversement. mais avec un bon petit génerateur de code, ce souci n'existe plus.
Angelo
a ce propos il existe un framework d'assemblage assez sympa qui s'appelle Dozer http://dozer.sourceforge.net/Par contre il est très rébarbatif de creer la classe Assembleur (ou autres choses) qui permettent de transformer un Bean en DTO et inversement. mais avec un bon petit génerateur de code, ce souci n'existe plus.
Je n'ai jamais utilisé dozer,
mais je connais une équipe qui l'a utilisé et ils ont plein de problèmes.
Dozer est tres puissant, mais je pense qu'il faut bien maitriser ses concepts avant de vouloir l'utiliser (c'est ce que l'on m'a dit). L'equipe a eu plein de problème avec les getters qui étaint mis en mode lazy. Dozer était un peu perdu et dans certain cas il y avait des boucles infinies. J'utilise aussi beanUtils aves sa méthode copyProperties, mais c pareil que dozer, c a manipuler avec prudence.
La conclusion que je me suis faite, c'est de developper completement la classe d'assemblage, car si il y a un problème, on peut faciement mettre un point d'arrêt pour detecter rapidement le probleme. Avec une API comme dozer ou Beanutils quand tout marche, c nickel, mais si il y a un problème on peut passer des jours a trouver le probleme (un moment j'ai du meme mettre les source de Beanutisl pour detecter le problème).
Moi je prefere utiliser un generateur de code qui me genere l'assemblage des Beans/DTO que je retouche ensuite pour les cas specifiques.
Angelo
-Je ne sais pas si Dozer est plus bugguée qu'une autre librairie, mais on a tous rencontré un jour des pbls avec des frameworks open-source (vrai bug, mauvaise doc, t'as pas assez dormi...), même sur les + populaires tels que Struts ou Hibernate. Dans l'idéal il ne faudrait jamais sortir des cas traités dans les "getting started" ou les tutorials, mais bon c'est le jeu aussi! d'où l'intérêt de récupérer le code source pour le debuging
-le problème de mapping d'objets entre couches est assez récurrent. Les développeur vont souvent coder en dur le mapping, ou selon la taille du projet mettre en place leurs propres fonctions de mapping soit avec l'api reflection ou avec beanutils. Mais si tu veux recopier des graphes d'objets, gérer les conversions de type, etc... tu peux te retrouver avec du code complexe et difficile à maintenir. D'où l'idée d'externaliser ca dans un assembleur paramétrable style Dozer.
Cela dit la solution avec génération de code est intéressante puisque le mapping est réalisé de manière statique (et donc on bénéficie du controle de type du compilateur + débugging facilité). Inconvénient : faut regénérer toutes les classes après toute modif (ca parait négligeable, mais on perd un peu en productivité, c'est pour ca que le mapping d'hibernate est réalisé à l'exécution).
En fait le choix entre dynamique / statique (génération de code) est un vrai débat ! chacun a ses avantages en terme de productivité/perf/maintenance. L'idéal c'est d'avoir les deux (émulateur + générateur). Un bel exemple étant le framework GWT.
Ton analyse est très juste.En fait le choix entre dynamique / statique (génération de code) est un vrai débat ! chacun a ses avantages en terme de productivité/perf/maintenance. L'idéal c'est d'avoir les deux (émulateur + générateur). Un bel exemple étant le framework GWT.
Oui c'est un vrai débat, étant donné que j'ai eu pas mal de mauvais expériences avec le dynamique, je préfère générer les classes que de rendre dynamique ce comportement. De plus ca me permet d'avoir la main pour gérer des cas spécifiques.
Angelo
Répondre avec citation
Partager