Ce n’est pas vraiment une question technique, mais plus de conception en fait.
Depuis peu, ma boîte s’est enfin décidé à commencer à migrer une certaine partie de notre applicatif en .NET. Etant donné que j’en avais fait pas mal dans mon coin, je me retrouve tout naturellement en charge (enfin pas tout seul quand même) de pas mal des nouveaux projets, pour au final tenter de rédiger nos « best practice » internes.
</mode mavie>
Depuis 1 mois je suis en train de construire pas mal de trucs autour du concepteur auto de DataSet qu’a apporté la nouvelle version.
Mais aujourd’hui, je me suis rendu compte d’un truc très bête. Je génére effectivement un DataSet fortement typé depuis des procédures stockées écrites avec mes petites mimines, mais jamais je ne m’en sers dans mon code Je ne fait appel qu’aux TableAdapter, DataTable et DataRow qu’il me génère. En fait, je suis parti du principe que mon TableAdapter, c’est ma couche d’accès au données, les row me servent de model object, qui vont donc se balader entre les couches, et par dessus je me code des objets métiers et une couche service si besoin est.
Mais avec cette approche, qui me parait propre, jamais je n’utilise directement le DataSet, et du coup utilise sa gestion des relations et autre. J’ai un peu l’impression de passer à côté de quelque chose en fait, mais je vois mal comment utiliser simplement les DataSet dans mon modèle. Donc si des gens mieux calés que moi en conception peuvent m’éclairer, je suis preneur.
on a codé la meme chose dans la boite ou je bosses, on a 3 couches ntiers qui s’occupe de bazarder la BDD en objets metier, et on travail avec ca. Le tout sans toucher aux dataset, ceux ci etant fait pour stocker des données, moins pour les manipuler (je suis clair la ?).
En gros → 3 couches : DataAccess avec les requetes, BizEnt, qui fait de la reflexion sur les tables (un champ = un assesseur), et Biz qui sont en fait des objets encapsulants les 2 couches superieures (on utilise ceux ci pour tout faire), et les Bizs (meme couche que les Biz au singulier) qui sont des Hashtable de Biz (representant un DataSet qui contient des DataRow etc…). Je sais pas si je suis clair, mais en gros, on a sensiblement la meme architecture que toi, environ 150 tables et ca tourne du feu de dieu, surtout quand c’est auto genéré en classe partielle pour ajouter/surcharger tes methodes (avec MAJ pour refleter les changements en base et tout).
Voili, en esperant que ca t’aide/conforte dans ton projet/idée.
bah, gerer les (collections de) biz (validation en base, CRUD etc…)
un peu comme le dataset va te manager tes datarow je crois (sachant que c’est pas moi qui bosse la dessus, on va arriver aux bouts de mes connaissance sur les Data*** du .net fwk)
Apres, tout ce que tu fais doit pouvoir etre faisable en utilisant les DataSet, mais pour ma part, on a tout recodé pour que l’outil de generation magique nous mache le travail (il mange de l’uml, et defeque du sql et du C# ou mange du sql direct sur la base pour nous pondre du C#).
Personnellement, j’ai toujours trouver les DataSet surtout utiles au RAD (pour réaliser une maquette d’appli orientée donnée) ou pour faire de la mise en cache / travail en mode déconnecté… Pour une appli en prod, j’ai tendance à m’en passer, a part pour les applis clientes “non connectées” ou ayant besoin d’une capacité à travailler en mode déconnecté.
Pour les applis Serveurs, j’ai écrit mon propre générateur de DAL (qui me génère du TSQL pour SQL Server 2000 / 2005 ou du PL/SQL pour Oracle à la demande ^^)… Avec bientôt une interface semblable aux générateurs de DataSet (merci les DSL tools).
Sinon, en ce moment je bosse pas mal sur DLinq, je commence à me poser des questions au niveau architecture… Comment tout ca va s’intégrer dans nos applications… Bref, c’est bien intéressant, et on peut dire que les ptits gars de chez MS sont en train de nous préparer le meilleur outil de mapping objet relationnel pour SQL Server directement gratos dans ADO.Net 3… Je connais des éditeurs qui doivent faire la gueule :s
Je ne fait appel qu’aux TableAdapter, DataTable et DataRow qu’il me génère. En fait, je suis parti du principe que mon TableAdapter, c’est ma couche d’accès au données, les row me servent de model object, qui vont donc se balader entre les couches, et par dessus je me code des objets métiers et une couche service si besoin est.