Discussion :

[jacklafrip]

Bonsoir à tous,

Le sujet peut sembler tout à fait provocateur, mais j'avoue ne pas bien comprendre l'intérêt d'un DataSet.
J'ai regardé les tutoriaux, lu certains des cours sur ce site, et je ne comprend toujours pas, ou alors les DataSet (et j'ai raté quelquechose dans ce cas), ne sont utiles que dans certains cas particuliers.

J'explique le but de mon programme ; vous pourrez sans doute m'expliquer où en mettre un, combien en mettre, et si, dans mon cas précis, cela sert effectivement à quelque chose.

Je travaille dans une petite société d'électronique qui externalise (en France ) sa production. Nous avons plusieurs produits, qui peuvent être fabriqués par plusieurs sous-traitants différents. Chaque sous-traitant, bien sûr, fabrique aussi plusieurs produits.
Nous nous occupons de faire un contrôle qualité des produits qui nous arrivent de nos sous-traitants avant expédition à nos clients, et c'est pour ce programme (que je vais créer de toutes pièces, ainsi que la base de données sur laquelle j'ai déjà réfléchi) que j'ai un problème.

Le but est d'avoir à la fois des données que l'utilisateur peut modifier (dans ce cas, le produit et le sous-traitant), et des données que l'utilisateur ne peut pas modifier(la version du produit, le numéro du contrôle, ...)

J'ai déjà écrit un programme qui va récupérer un certain nombre de ces informations dans un fichier XML et qui génère un pdf à partir des informations récoltées. Le problème, c'est que ce fichier XML ne permet pas de stocker d'informations utiles à des statistiques sur les sous-traitants, les différents problèmes rencontrés, ...

Vous trouverez en pièce jointe une capture d'écran du programme existant.
Pour la nouvelle version, j'ai déjà commencé à vérifier que je pouvais me connecter à ma base de données. Quel serait, dans mon cas, l'utilité d'un DataSet alors que je pourrais écrire toutes mes requêtes à la main ?

Merci pour vos réponses.

[Contrec]

Bonjour,

Personnellement, je me sers des DataSet pour pouvoir avoir une vue d'ensemble de ma base de données. Je crée un DataSet et plusieurs DataTable qui représentent mes futures tables physiques.
Grâce à l'outil graphique de Visual Studio je peux ainsi me concentrer sur la structure de ma base de données sans me soucier si elle sera SqlServer ou MySql ou autre (car la conception est totalement décorrélée de la base de données physique à ce niveau).
Le DataSet me permet de mettre des contraintes entre mes tables (unicité, champs non nulls, clés primaires etc...) et de savoir que l'application les respectera (car plus tard quand tu manipulera ces données dans des contrôles graphiques, tu auras automatiquement des erreurs remontées si ces règles ne sont pas respectées). Donc pour résumer ça permet d'avoir une base de données "propre" et pas corrompue par de mauvaises manipulations.

De plus je peux facilement lier ("binder" comme on dit) tes DataTable avec tes contrôles graphiques (l'exemple le plus parlant est la DataGridView) ce qui te fera économiser un temps énorme car tu n'auras pas à formatter les données, créer les bonnes colonnes avec les bons types etc...
Et quand tu veux modifier les données, le DataTable te permet d'identifier les lignes que tu as ajouté/modifié/supprimé pour pouvoir facilement tout sauvegarder d'un coup ou faire des traitements spécifiques (car les DataSet et DataTable embarquent beaucoup de fonctionnalités).

Donc je trouve un très grand intérêt à utiliser les DataSet (gain de temps, conception sans lien avec un SGBD particulier, respect des contraintes de BDD).

En fait on devrait même être obligés de les utiliser sous peine d'amende

J'espère que ça t'aidera à y voir plus clair. Bien sûr c'est mon avis personnel, il doit y avoir encore d'autres bonnes raisons de les utiliser.

[jacklafrip]

Merci Contrec pour ces réponses.
L'intérêt me paraissait, à un moment, de ne pas avoir à écrire de requêtes, VS s'en occupant tout seul. J'ai l'impression que cela est faux, et que les requêtes doivent être toujours écrites.
Je comprend déjà mieux les DataSet, et leur intérêt pour ne pas interroger de manière incessante la base, mais plutôt les DataSet.

[Contrec]

Oui les DataSet viennent "couvrir" ta base de données en te donnant des fonctionnalités prêtes à utiliser, plutôt que ce soit à toi de tout coder.

Pour les requêtes SQL, tu auras quand même à les écrire pour celles qui sont "spéciales" sinon lorsque tu créer dans l'outil graphique un DataTable, les requêtes Ajout/Modification/Suppression sont automatiquement crées.

[Nathanael Marchand]

Ah ben j'aurais dis le contraire! Personellement, je n'utilise jamais de DataSet.
Les DataSet sont pour moi utiles que dans des cas très spécifiques (aggrégation de plusieurs sources de données par exemple ou scénarios offlines par exemple).
Dans un cas normal, tu utiliseras plutot une couche d'accès aux données qui te retourne des entités objets qui refletent les entités de ta base (via un ORM comme LinqToEntities/NHibernate ou même à la main).

A mon gout, le DataSet est beaucoup trop utilisé pour rien. Un héritage de VB ou il te suffit de drag n dropper tous tes éléments sur ta form dans le designer et pouf ca marche. Sauf que développer proprement c'est un peu plus que ca et que ce genre d'appli c'est vite une catastrophe en perfs et à entretenir.

[ThomasR]

Ah ben j'aurais dis le contraire! Personellement, je n'utilise jamais de DataSet.
Les DataSet sont pour moi utiles que dans des cas très spécifiques (aggrégation de plusieurs sources de données par exemple ou scénarios offlines par exemple).
Dans un cas normal, tu utiliseras plutot une couche d'accès aux données qui te retourne des entités objets qui refletent les entités de ta base (via un ORM comme LinqToEntities/NHibernate ou même à la main).

A mon gout, le DataSet est beaucoup trop utilisé pour rien. Un héritage de VB ou il te suffit de drag n dropper tous tes éléments sur ta form dans le designer et pouf ca marche. Sauf que développer proprement c'est un peu plus que ca et que ce genre d'appli c'est vite une catastrophe en perfs et à entretenir.

Bonjour,
Si il suffit de "drag n dropper" et "pouf" çà marche, quel mal y-a-t-il ? J'y verrais ici plutôt un avantage...

Aussi, tu te trompes complètement lorsque tu dit que développer proprement c'est plus que çà, n'oublies pas qu'ASP.net est un framework, et qui dit framework dit outils de travail, Dataset en fait partie. Concernant les perfs c'est encore faux, il est bien plus performant d'utiliser un dataset et de le stocker en mémoire (shared / static) que de faire des requêtes au SGBD. Et pour cela le simple ajout d'un mot clé suffit à parvenir à cette implémentation, alors que tout coder à la main requiert bien plus de temps.

Je n'utilise que rarement le Dataset car je trouve aussi que cela implémente beaucoup de logique métier pour parfois pas grand chose. Mais cela offre malgré tout un certain confort, un gain de temps considérable (que ce soit à la création ou la mise à jour du schéma), et d'excellentes performances lorsque bien utilisés.

[jacklafrip]

Béh dis donc, je pensais pas que cette question ouvrirait un conflit entre modérateurs
Globalement, pour dégager un point de vue semblable entre vous deux, le DataSet, ça peut être bien dans certains cas, mais il faut l'utiliser avec précautions.
Je pense donc suivre la voie du "codage à la main", en utilisant, lorsque cela me semble utile, un DataSet : comme ça, tout le monde est content !

[calagan99]

Aussi, tu te trompes complètement lorsque tu dit que développer proprement c'est plus que çà, n'oublies pas qu'ASP.net est un framework, et qui dit framework dit outils de travail, Dataset en fait partie. Concernant les perfs c'est encore faux, il est bien plus performant d'utiliser un dataset et de le stocker en mémoire (shared / static) que de faire des requêtes au SGBD. Et pour cela le simple ajout d'un mot clé suffit à parvenir à cette implémentation, alors que tout coder à la main requiert bien plus de temps.

Sur la question des perfs... je demande à voir...

Pour avoir maintenu une vieille appli avec une grosse quantité de données qui utilisait des DataSet, je peux t'assurer qu'une fois la partie accès aux données migrée et l'utilisation des DataSets stoppée, on a retrouvé des perfs dignes de ce nom.

A mon sens, le DataSet n'a plus qu'un intérêt en mode deconnecté. Pour le reste, les cas d'utilisation à bon escient sont assez marginaux.

[ThomasR]

Sur la question des perfs... je demande à voir...

Il est évident que si tu construis ton dataset à chaque requête les performances sont exécrables.

[calagan99]

Il est évident que si tu construis ton dataset à chaque requête les performances sont exécrables.

Nous sommes donc d'accord
Cela dit, pas sûr que tout le monde soit au point sur le sujet...
Ce qui confirme que l'utilisation du DataSet répond aujourd'hui essentiellement à un scénario déconnecté.

[olibara]

Personnellement je n'utilise jamais de dataset mais des datatables en mode déconnecté

Pour la visualisation, une datatable bindée a un datagridview c'est un vrai plaisir

Et pour les editions dans la DB j'ai écris mon propre generateur de classe a partir du schema de la DB
Ca n'exclut pas le tuning "a la main"

Mais c'est beaucoup plus souple, maitrisable, performant et moins lourd que des usines à gaz comme Linqtoentities ou Nhibernate

[Nathanael Marchand]

Un dataset partagé entre utilisateurs? Mais quel horreur
Quid des opérations transactionnelles?
Rares sont les cas ou il faut avoir des accès aux données statiques!

[olibara]

Un dataset partagé entre utilisateurs?

Qui a dis ca ?

[calagan99]

Mais c'est beaucoup plus souple, maitrisable, performant et moins lourd que des usines à gaz comme Linqtoentities ou Nhibernate

Question de point de vue...
Il faut simplement utiliser les ORM à bon escient.

Je travaille actuellement sur une appli qui tape plusieurs bases de données dont la principale contient une quantité non négligeable de données.
Certaines tables dépassent les 10M d'enregistrements. Sur ces dernières, nous requêtons à la main.
Sur d'autres tables moins remplies, c'est NHibernate qui fait le boulot pour nous, et tout se passe bien.

Avancer que les ORM sont d'emblée des usine à gaz revient à se priver d'une possibilité de simplifier son code et de diminuer les temps de dev de certaines parties non critiques de tes applications pour pouvoir se concentrer sur les parties plus importantes.

[Nathanael Marchand]

Qui a dis ca ?

Ci dessus:

Aussi, tu te trompes complètement lorsque tu dit que développer proprement c'est plus que çà, n'oublies pas qu'ASP.net est un framework, et qui dit framework dit outils de travail, Dataset en fait partie. Concernant les perfs c'est encore faux, il est bien plus performant d'utiliser un dataset et de le stocker en mémoire (shared / static) que de faire des requêtes au SGBD.

Si il suffit de "drag n dropper" et "pouf" çà marche, quel mal y-a-t-il ? J'y verrais ici plutôt un avantage...

Ah bah oui! C'est sur que mettre les requêtes SQL dans le code-behind de ma form c'est génial, c'est méga propre!

Soyons sérieux, le drag'n'drop ca va bien pour faire une maquette en un temps éclair mais pas plus!

[ThomasR]

Ci dessus:
Ah bah oui! C'est sur que mettre les requêtes SQL dans le code-behind de ma form c'est génial, c'est méga propre!

Soyons sérieux, le drag'n'drop ca va bien pour faire une maquette en un temps éclair mais pas plus!

Je ne parle pas de les mettre dans la form (n'importe quoi), je parle évidemment du constructeur de dataset, clic droit => nouvel element => dataset => drag and drop des tables dedans => ca créé des entités fortement typés.

Aussi, ceci n'a rien a voir avec la question "dataset partagé entre utilisateurs". J'ajouterais sur ce point qu'un SGBD est également partagé entre les utilisateurs. Bien sûr, si moultes transactions il y a, le dataset n'est pas adapté (ou nécessite d'implémenter divers procédés programmatiques).

[Contrec]

Bien utilisés, les DataSet peuvent être vraiment pas mal et évitent justement les erreurs communes que tu peux avoir si tu fais tout "à la main". Quand je rajoute des contraintes de clé primaire sur ma DataTable, je peux être sûr que derrière j'aurai une vérification systématique de cette contrainte...

Après tout, le Framework me donne des outils testés et approuvés au fil des versions et je les utilise.

C'est sûr que pour 2 tables, implémenter un DataSet peut sembler assez lourd... mais pour des applications un peu plus importantes, je pense que c'est plutôt un atout... en tout cas le résultat est très satisfaisant. Bien évidemment, pour tirer le meilleur des DataSet, il faut bien en comprendre les principes avant... Le DataSet ne pourra pas t'offrir de meilleures performances si à la base tes requêtes SQL sont pourries.

J'ai l'impression que l'on a tendance à vouloir critiquer les choses que l'on ne connait pas trop (je ne vise personne en particulier car je ne connais personne, c'est une constatation dans mon entourage professionnel).

Bref je donne mon avis :

+1 Pour les DataSet

[calagan99]

Vous précisez que le framework fournit des outils simples à mettre en oeuvre et éprouvés.
Certes, mais l'utilisation du DataSet était un outil simple et éprouvé en DotNet 1.1 et à la rigueur en 2.0.
Depuis, il semble quand même que Microsoft ait pris une autre direction. Ce n'est probablement pas un hasard...

[Contrec]

Donnée que je n'ai pas, tu as un lien pour étayer stp ?

Je suis intéressé car en effet si Mircosoft déconseille d'utiliser les DataSet de leur propre Framework, je veux bien arrêter moi aussi de les utiliser...

[Nathanael Marchand]

Et je répète que les accès aux données ne doivent pas être partagés: Ni static, ni singleton!
Il faut gérer les isolations des utilisateurs par des transactions.
La bonne pratique est la suivante: en client lourd, une transaction par fenetre de GUI, en web/webservice, une transaction par requête.