[ARCHI J2EE] action->service->DAO

Bonjour,

Je me pose des questions sur un point concernant les archi n-tiers.
Je suis dans le cas d'une appli struts/hibernate.
Je veux faire des tableaux de reporting dans ma partie struts.
Pour le moment je creais ma jsp et faisais appel dans mon action a une methode de ma DAO qui me renvoyait une liste d'objets a afficher.
Cas d'ecole !
Mais on me dit qu'il ne faut pas faire appel aux DAO dans la partie presentation ... mais qu'il faut passer par la coucher service.
Pourquoi pas ... mais cela impliquerait que je cree une service wrapper de ma dao pour chq dao dont j'ai besoin dans ma couche de presentation ?
Que pensez vous de cela ?

merci de vos conseils

D'un point de vue archi, et d'une manière générale, raisonner en termes de services + dao est une bonne chose. Les dao sont dédiés au chargement d'objets et les services vont, éventuellement, faire appel à plusieurs dao pour retourner des grappes d'objets.
Maintenant c'est à toi de voir ce que fourni ton dao. Si c'est exactement un objet "simple" et que tu ne mets pas trop d'intelligence métier dans le dao, c'est totalement jouable. A toi finalement d'imaginer des scénarii d'évolution de ton application pour voir si les options que tu prends ne seront pas un obstacle trop lourd par la suite.
Mon avis, ayant fait du reporting financier, je partirai quand même sur service+dao (mais là ce n'est qu'un avis de vieux qui se dit que cela ne coûtera pas plus cher, ne sera pas plus lent et préparera sûrement mieux un avenir que l'on sait souvent incertain)

A toi de choisir.......;)

Bonjour ego,
le role de la couche service, permet de gerer ton metier (ex : lors de la creation d'un utilisateur, on verifie que le login n'existe pas). Au premier abord, on peut se dire, que ce test métier peut s'effectuer dans la couche Action Struts. Mais maintenant imagine qu'une autre Action ou une autre Application, souhaite aussi créer un utilisateur, ceci necessite de dupliquer ce test métier.
La couche service permet entre autres de proposer des composants métier qui sont à la disposition de l'entreprise.

Si tu es interesse, j'ai tente de decrire l'architecture service/DAO dans mon projet open source GestCV que tu peux trouver sur http://gestcv.sourceforge.net/fr/architecture.html

Angelo

A ce propos je te recommande le document sur le modèle MVC présent sur ce site.
Ca vaut le coup

Bonjour,
je vois tout a fait l'archi multi-tiers et comment elle se presente.
Ma question etait tres ciblee : dans un cas de reporting !
En gros je ne fait appel qu'a des requete HQL dont j'affiche le resultat : il n'y a pas de code metier !
Dans ce cas precis, cela est il handicapant pour la maintenance et l'evolution de rajouter une couche de service entre la DAO et mon action struts, ou est ce que cela pour s'averer interessant en terme d'evolutivite de l'applicatif.
Car en fait ma couche de service, si je la rajoute, ne fera que wrapper mes methodes de dao.

Merci de vos conseils et de vos retours

Non, ce n'est pas pénalisant du tout, rassure toi.
Cela vas au contraire t'apporter un niveau d'isolation entre ta couche de présentation et ta couche de données.

D'un point de vus purement métier, sache que c'est le cas d'utilisation qui doit être transactionnel (ACID) et non l'accès unitaire à la base de données aussi, cela t'apporteras une plus grande souplesse pour gérer cet aspect sur tes applications.

Bonjour ego,
si tu veux supprimer la couche métier, en utilisant Hibernate, il faut faire très attention aux appels de tes méthodes getter des tes objets (Bean, model,...) que tu mappes avec Hibernate.

En effet les objets mappes par Hibernate sont persistents, et donc surveilles par la session factory. Autrement dit si lors de l'edition de ton rapport tu fait appel a un getter qui se declenche en mode lazy, ceci va tenter d'executer une requete, et si ta session est ferme, tu risque d'avoir des problemes.
A ce probleme, plusieurs solutions :

1. copie des informations Bean dans une DTO (normalment c la couche service qui s'en occupe). Du coup dans ton rapport tu travaiiles avec des DTO et pas des Bean (qui sont surveilles par la session factory).

2. detachement de tes objets Bean (session.evict je croies).

3. garder la session hibernate tout le long de la generation de ton rapport, puis la fermer a la fin (voir Open In View dans les forums Hibernate), mais ca je ne le conseille pas trop.

Bon courage

Angelo

J'utilise en effet l'open session in view.
Mais g du mal a comprendre :

Citation:

---

D'un point de vus purement métier, sache que c'est le cas d'utilisation qui doit être transactionnel (ACID) et non l'accès unitaire à la base de données aussi, cela t'apporteras une plus grande souplesse pour gérer cet aspect sur tes applications.

---

Cela voudrait dire que ce sont mes methodes metiers qui doivent etre transact et non mes operations atomiques sur la base de donnees ?

Merci de vos retours

Oui ;)