Discussion :

[Dufok]

Bonjour,

En vue d'un nouveau projet qui va m'être confié, une question me turlupine : dans les architectures classiques 3 tiers, je ne vois pas comment gérer correctement mes transactions dans mon futur code.

Je m'explique. Prenons le cas classique d'une université : un élève s'inscrit et il faut l'ajouter dans une classe et à l'internat.
Je vais donc faire :

- Une classe EleveDAO
- Une classe service Eleve

- Une classe ClasseDAO
- une classe service Classe

- Une classe InternatDAO
- une classe service Internat

Je continue J'ai maintenant besoin de faire une classe Inscription, dans laquelle je fais une méthode "inscrire" qui fait par exemple (le code ci-dessous est mauvais, mais c'est pour l'exemple )
- Eleve.Ajouter() qui appelle EleveDAO.Ajouter(me)
- Classe.AjouterEleve() qui appelle ClasseDAO.AjouterEleve(...)
- Internat.AjouterPensionnaire qui appelle InternatDAO.AjouterPensionnaire(..)

Bien entendu, si une des ces méthodes ajouter échoue, il faut faire un rollback. Il faudrait donc que ce soit les procédures de la couche "service" qui gèrent les transactions. Mais :
- il faut que mes classes service restent indépendantes de la technologie utilisée par la couche DAO.
- si chacune des classes services gèrent leurs propres transactions, il faudrait dans chacune d'elles, avant de démarrer une transaction, vérifier qu'aucune n'est en cours.

Comment faire donc pour faire propre et simple ? Utiliser des outils fournis par nHibernate ? J'ai fouillé partout sur le net sans trouver de réponse claire à mon problème.

Merci pour vos futures lumières

[Philippe Vialatte]

Salut,

bon, je ne vais pas remettre le couvert, mais déjà, j'aimerais que tu clarifies ce que tu entends par MVC

Bien entendu, si une des ces méthodes ajouter échoue, il faut faire un rollback. Il faudrait donc que ce soit les procédures de la couche "service" qui gèrent les transactions.

Pas forcément, dans l'absolu, tu peux aussi considérer que tu as une méthode "Inscrire", qui descends directement dans la couche DAO, et qui regroupe la partie transaction.

Si tu veux le gérer au niveau service, le plus simple est d'utiliser TransactionScope, qui devrait faire l'affaire.

Normalement, ca doit fonctionner avec NHibernate (ca marche bien avec Subsonic, alors j'espère bien que NHibernate le fait aussi )

[Dufok]

Merci !

Tu as répondu trop vite Je me suis rendu compte de ma boulette en postant mon message hier soir, j'ai corrigé par "3 tiers" à la place de MVC

Je viens de regarder vite fait la classe TransactionScope. Ca a l'air plutôt pas mal

Avec un tel outil, vaut-il mieux mettre la gestion des transactions au niveau DAO ou au niveau service ?

[Philippe Vialatte]

Avec un tel outil, vaut-il mieux mettre la gestion des transactions au niveau DAO ou au niveau service ?

Réponse classique, "ca dépends"

En général, pour les transactions, j'aime bien les laisser dans la partie DAO, vu qu'une transaction, c'est un opération de bases de données, après tout...

Le problème, c'est que si tu veux prévoir un peu "pour l'avenir", il faut prendre en compte le plus simple à utiliser pour la maintenance, et dans ce cas la, le plus simple est d'utiliser TransactionScope directement dans la couche Service...mais ca a tendance à me brosser dans le mauvais sens du poil (ceci dit, c'est probablement des vieux restes de l'époque ou on faisait du "tout proc stoc")

[Dufok]

Merci, je vais étudier tout ça !

L'époque "tout proc stock" je n'ai pas connu, je découvre juste : on m'a confié la maintenance d'un vieux projet rempli de ce genre de trucs

[Maximil ian]

Salut,

A un niveau plus conceptuel, le pattern Unit of Work proposé par Martin Fowler semble répondre à tes besoins.

Il peut être implémenté à l'aide de TransactionScope et découplé de la DAL (persistence ignorance).

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx
http://www.geekzone.fr/ipb/index.php...dpost&p=724327
http://sergeyshishkin.spaces.live.co...D63F!265.entry

[Philippe Vialatte]

A un niveau plus conceptuel, le pattern Unit of Work proposé par Martin Fowler semble répondre à tes besoins.

Il peut être implémenté à l'aide de TransactionScope et découplé de la DAL (persistence ignorance).

NHibernate est justement basé sur Unit of Work

[B.AF]

NHibernate est justement basé sur Unit of Work

Pas trop justement, j'ai plutôt l'impression qu'il cherche un active record avec une transaction propagée.

Maintenant imaginons le cas suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
 
using (ISession s=Dal.GetSession())
{
 
     s.SaveOrUpdate(_eleve);
 
}

C'est suffisant : chaque ISession détachée par la session factory de Nh sont des unit of works.

Après on peut encore ajouter des transactions dessus, mais ça n'est pas très utile!