[.NET] [et autre d'ailleurs] Question d'architecture

Voilà, je me pose une question quasi-existentielle et j’aimerais avoir l’avis de ceux parmi vous qui ont de la bouteille coté programmation orienté objet.

Lorsque votre appli doit s’appuyer sur une base de données, comment organisez vous les accès aux données ? Je m’explique.
Imaginons une table Utilisateurs dont vous voulez récuperer un utilisateur pour le mettre dans un objet d’une classe utilisateur. Est ce que vous allez implémenter une méthode “Initialiser(idUser)” dans cette classe qui se charge de récuperer les infos en créant la connexion, la commande, le datareader, etc…ou est-ce que vous allez plutôt creer une classe appellé Base par exemple, qui se charge de tous les accès à la base de données, et qui possèderait une méthode du style “InitialiserUtilisateur(idUser)” qui renvoie un objet utilisateur ?
Avantages inconvénients des deux techniques ? 

Je sais que ce n’est pas une question qui se rapporte directement au codage, mais bon, ça devrait passer quand même…

P.S. et pendant que j’y suis, si Glop passe dans le coin, est-ce qu’un prochain dossier sur .NET est prévu ? Parce que le 1er est bien sympa alors j’attends la suite avec impatience…

Note: desole pour l’ignoble franglais mais je connais la technique qu’en anglais donc excusez mon VanDame

Je sais pas a quel point tu veux t’avancer sur ce chemin en fait Selon la taille de ton applications et selon tes besoins est ce que tu veux vraiment mapper chacune de tes tables a des vrais objets et faire un vrai mapping relationel de ta base de donnee. Si j’ai mal pige ton message desole du gros “rant“ mais si tu penses t’engager dans le developpement complet ou tu vas abstraire completement la base de donnees du front end avec des tels objets il y a plein de choses a prendre en compte.

Deja l’important avant de commencer a partir la dedans, c’est “est ce que j’ai vraiment besoin de faire du data mapping comme ca?”. Est ce que tu as tellement besoin de scaler que tu as besoin d’un middle tier dedie qui ne fera que generer ces objets. Ensuite si c’est distribue comme ca quelle est ta strategie de communication entre le middle tier et le front end? Remoting? Si c’est du planning pour le futur est ce que c’est vraiment un futur proche? As tu bien definit tes strategies de transaction et de concurence avec un middle tier objet independant comme cela, locking optimiste, pessimiste, dans quel cas, etc? Quelle est ta strategie de mapping? Une instance d’un utilisateur avec ID=1 mappe elle exactement avec ta ligne dans ta base de donnee (interdisant d’avoir une seule autre instance d’un objet avec ID=1 en memoire a un instant t)? Est ce juste un moyen de passer des donnees elegament entre les differentes parties de ton application? Si tu as une foreign key dans un de tes objets mappes vas tu construire tout l’arbre d’objets agressivement a la premiere requete ou rester “feignant“ et aller les chercher “on-demand“. Qu’est ce que tu vas cacher et comment? Plein plein de questions qui ont pas du tout de reponses triviales et passe partout et qu’il faut se poser si tu veux faire un mapping complet. Des gens vendent des solutions a des millions de francs pour repondre plus facilement a ces questions (BEA weblogic, IBM websphere, JBoss (Gratos), etc).

Il y a eu une “mode” du relational data mapping il y a pas si longtemps (en particulier grace/a cause des EJB en java) et tout le monde voulait tout faire en utilisant tout le temps des EJB. Comme toute les modes, ca passe, et on se rend compte que c’est pas forcement la meilleure solution pour beaucoup de problemes. Ca amene un niveau de complexite qui est loin d’etre desirable a tout les projets. Bien entendu c’est adapte dans certains cas. Personellement utiliser ce genre d’objets de mapping a part dans des cas equivalent a des “session beans” je suis pas super partisant a part dans des cas d’architecture enterprise ou il faut vraiment un middle tier independant et complet. Dans ce cas la, de toute facon, personne n’ecrit les classes individuelles a la main. Pour repondre a ta question cela dit, en general on fait un classe XXXFactory qui est la classe reponsable de creer les objets XXX, et qui contient le code necessaire. Bien sur on factorise tout ce qu’on peut dans une/des classes de base. Il existe des outils de gestion de mapping relationel en C# aussi bien qu’en java (bien que bcp plus developpees en java).

Si ton archi n’a pas besoin de tout ca je pense qu’un “strongly typed dataset” (ou meme pas strongly typed dans les cas les plus simples) fera mieux l’affaire pour la plupart des tes besoins. Si tu as pas vraiment besoin de t’abstraire de la DB et pour une petite appli, c’est n’est pas un peche capital que d’acceder a la DB depuis le frontend. Si tu trouves ca plus propre ou que ca fait parti des besoins de l’appli il y a des moyens sans aller tout au bout, comme les typed dataset. C’est une philosophie differente et je suis d’accord que le mapping simple peut sembler plus intuitif au premier abord dans beaucoup de cas, mais c’est pas pour ca qu’au final quand on comprend bien les deux c’est plus simple a mettre en place comme il faut. Rien ne t’empeche bien sur de creer un/des objets de mapping partiel pour des cas limites a un role de gestion de session par exemple, comme un objet utilisateur. Mais je te conseille fortement de regarder vers de solutions plus simples comme les typed dataset en .net.

PS: pour les articles, oui, mais en fait pratiquement non j’ai pas le temps.

Ce message a été édité par GloP le 25/02/2004

Je vais te donner une réponse bien moins technique que celle de Glop
Je n’ai jamais bossé sur des projets monstrueux, et j’ai appris à programmer sur le “tas”.
Mais que ce soit en php ou en C#; j’utilise toujours une classe qui accède aux données. Je ne passe jamais directement par ma classe qui va traiter ces données (que ce soit pour un simple affichage ou autre)…
Pourquoi je fais cela ? Pour 3 raisons principales en fait:
1 - Le code est plus clair et plus élégant
2 - Si tu veux changer de SGDB, rien ne t’en empêche: tu as juste à ré-écrire ta classe d’accès aux données (pas toujours, mais si tu changes de bases de données qui sont très éloignées l’une de l’autre (je pense à MySql et SQLServeur, où le premier n’accepte pas les requètes imbriqués par exemple)).
3 - Et enfin, si tu veux ré-écrire le code qui traite les données (cf affichage), tu ne ré-écrit que cette protion de code.

Enfin, pour reprendre un peu ce que dit Glop, en C# (et sous .NET en général), tu as les dataset qui sont hyper-pratiques pour le “passage” des données entre tes objets.

C’est vrai que pour ce que je veux faire, ce n’est pas forcément obligatoire. Je commence une appli .net en C# pour apprendre le C# en fait, donc je peux me passer du data mapping.

J’ai bien fait de te poser la question car je ne connaissais pas le “typed dataset” (je ne connais pas encore grand chose de C# à vrai dire ). Le dataset simple, OK je sais faire.
Par contre le “typed” généré à partir d’un fichier XSD, ça m’a l’air bien intéressant (j’ai regardé un peu la doc) mais ça n’a pas l’air simple cette histoire. Il n’est pas possible de générer directement le dataset typé sans devoir faire à la main le fichier XSD (question à moi même qui ne demande pas de réponse pour l’instant) ?

Bon je vais potasser ça et je reviendrais si c’est vraiment trop compliqué (faut quand même que j’essaye de trouver le truc tout seul, dediou!!).

Merci pour les infos Glop

Aristidi : je fais effectivement comme toi d’habitude, mais je voulais un peu avoir l’expérience d’autre personne.

P.S. : Toujours trops justes ces journées de 24 heures

Ce message a été édité par knkrath le 25/02/2004

Heureusement qu’on ne crée pas ce truc à la main. Visual Studio le fait pour toi.
Pour toutes ses questions, un site de référence en français existe: http://www.dotnetguru.org

Je viens de trouver cet excellent article:

http://www.c-sharpcorner.com/Code/2004/Feb…SetsIn.NET1.asp

Il est simple, clair et concis… (mais en anglais)

sympa comme article. merci.

ça tombe assez bien justement parce que en ce moment je fais mumuse avec ADO.net et C#, et en particulier avec le disconnected mode…