NHibernate, architecture, utilite

Bonjour tout le monde,

Je viens de lire attentivement le tutoriel sur NHibernate, ainsi que plusieurs articles sur le net et aussi un discution avec un ami qui bosse avec la version pour java depuis 2 ans.

Et je reste septicque dans mon cas precis, je m'explique :

Nous sommes plusieurs equipes l'une d'entre elle est dedie base de donnees, et une est dedies soft, je suis dans l'equipe soft.

L equipe base de donnees, a pour mission de controle toutes les bases de donnees des applications de fournir des procedures stockees, les tables brefs tous ce dont on peut avoir besoin pour travailler.

J'ai pour mission de developper un nouveau soft, qui est lies a une base de donnees, ce que j'ai prevus comme archi est la suivante :

DataAccesLayer
BusinessLogicLayer
BusinessObject

Cette archi est developpee dans le tutorial "developpement N-Tiers" dans le forum Dot.Net

Voila mon probleme est que mes collegues de base de donnees vont vouloir controler la persitance des donnees dans la base via des procedures stockees.

Que pensez-vous Nhibernate dans mon cas?
Je suis preneur de toute discution. Si je suis pas clair n'hesitez pas a me le dire.

Merci
Superfly.

Je vais résumer.

NHibernate te permet de faire du mapping=> ton collègue conçoit la BD. Et toi tu "mappes" tes objets au niveau de ta BLL pou accéder à la DAL...

De plus, il est possible d'utiliser des procédures stockées existantes sur le serveur. Donc, il n'y a aucun problème.

Cependant, je ne te conseillerai d'apprendre (N)Hibernate sur un projet "d'entreprise" parce que si tu te plantes, c'est la porte :aie:

Essaie de mieux préciser ton problème, parce que j'avoue que j'en vois pas.

salut Giovanny Temgoua,

Eh bien je vais essayer de preciser ma penser le plus clairement possible.

Citation:

---

NHibernate te permet de faire du mapping=> ton collègue conçoit la BD. Et toi tu "mappes" tes objets au niveau de ta BLL pou accéder à la DAL...

---

Je suis pas tellement d'accord pour moi les objects se mappent sur les BusinessObject la BBl est uniquement appele par le GUI. Mais je me trompe peut-etre?

Sinon pour ce qui est d'apprendre Nhibernate sur un projet d'entreprise pour l'instant ce n'est qu'a la phase d'etude, et je ne suis pas chaud pour l'instant ;-) Je vais m'expliquer.

En faite j'ai travaille ces derniers annees en utilisant le Test Driven Developpement et l'extreme programming.
Je suis donc un peu obnipuler par les tests.

Et je trouve qu'il y a trop d'adherance a la base de donnees dans le framework Nhibernate, j'ai besoin de pouvoir boucher mes classes par des mock ou autre, pour pouvoir tester le tout.

Il me faut donc des interfaces un peu partout pour ne pas avoir de mauvaise surprise.

En fait pour moi, mes differentes couches doivent pouvoir marcher toutes seules.

Suis-je un peu plus clair?

Merci
Superfly

Ce n'est pas avec la BOL que tu dois faire le mappage mais bien la BLL.

Les objets Metiers sont des représentations mémoire et quelques axiomes, mais ne devraient dans l'absolue, pas avoir de dépendances directes à la DAL.
Sinon tu n'a plus d'intérêt à avoir une BLL qui s'occupe de la logique de traitement associées à la BOL.

Mais là on en revient à l'architecture N-tiers.

Ensuite je suis d'accord avec Giovanny Temgoua, n'apprend pas NHibernate pour un projet d'entreprise, car pas le droit à l'erreur.

Moi j'ai un très gros projet sur le dos et n'utilise pas du tout NHibernate, cela dit la structure de la base de données est tellement spéciale que ca ne menerais nul part, et puis les objets types DataSet ne me servent qu'a récupérer les resultset de mes procédures stockées... donc je me contente très bien d'ADO.NET malgré son modele de fonctionnement. (qui ne convient pas aux architectures N-tiers)

Pour revenir à l'architecture N-tiers et l'extreme programming ou aussi la manie de faire des tests sans arret et pour tout... c'est possible, de tester les différentes couches mais pas forcément séparémment.
Il suffit de procéder dans l'ordre.

la DAL peut etre testée seule, elle devrait etre la première a etre parfaitement mature.
la BOL peut etre testée seule.
la BLL ne peut pas etre testée seule, pour fonctionner elle a besoin de la BOL et de la DAL, puisqu'elle sert de "Liaison Logique" entre les deux, d'où Business Logic Layer.

C'est la couche à tester en dernier lieu. En réalité, chaque élément de la BLL peut etre testé dès que l'objet métier associé est prêt, du moins sa déclaration.

Tester pour tout c'est bien, mais nécessite d'ordonnancer tes tests dans le cas d'une architecture n-tiers.
Cependant l'avantage c'est que tu peux tester indépendamment le niveau fonctionnel de ton objet métier, et le niveau opérationnel.

Salut cinemania,

J'ai pas l'intention d'utiliser Nhibernate toute de suite car je suis pas pret, rassurer vous je suis pas sucidaire je viens juste d'arriver dans cette nouvelle tole.
Et il y a tellement a faire ici que je ne veux pas m'ajouter de pression supplementaire!

Je vous explique comme j'ai vois mon archi N-Tiers car tout mes problemes viennent peut-etre de la en faite.

BusinessLogicLayer :
- ClientManager.cs () : Donne un singleton et une method qui retourne lq liste des clients de la BD en appelant la methode correspondantes dans ClientDAO.cs

BusinessObjectLayer :
- Client.cs : Class object pure et dure represente un client (id, nom, prenom)

DataAccessLayer
- sql.cs : Donne un singleton et une donne une connection et la close
- ClientDAO.cs : Donne un singleton et donne la liste des clients de la DB sont la forme List<Client>

GUI
- le site web

Voila c'est basiquement l'exemple de l'article Architecture N-Tiers du forum, donc en faite en y reflechissant si je devais mapper je mapperais sur ClientDAO, mais dans ce cas a quoi me servirait mon Client.cs?

Je dois avouer que je suis un peu perdu dans le mapping. Merci de m'aider.

Sinon pour en revenir au test, il est toujours possible de tester composant par composant en ecrivant des classes "bouchons", neammoins il faut se mefier du temps que l'on peut y passer ;-)
Et surtout ne pas oublier que le test pour le test n'a pas d'interet.

Merci pour votre aide.
Superfly

En fait ton mapping va se faire entre ClientDAO et ClientManager, mais surtout pas au niveau de Client.

Client va te servir uniquement pour le reste des opérations... il représente un objet métier sans les préoccupations du genre, ou on le stocke, comment...

Pour cela ton application utilisera ClientManager qui utilisera ClientDAO ou autre chose, en fonction de ce que tu lui demande.

salut tout le monde,

J'ai encore une petite question sur le mapping.
En fait je comprend pas tres bien pourquoi tu dis que le mapping se fait entre les classes ClientDAO et ClientManager entre ces classes sont dans des couches differentes?
C'est pas super clair dans ma tete, desole.

J'ai definitivement renonce a l'utiliser en projet entreprise, par contre pour une petite appli maison ;-) sa peu etre sympa pour ce faire la main, un we ou j'aurais rien a faire ;-)

Merci
Superfly