Discussion :

[sajedose]

Lequel utliser ,un dataset ou un dataredear dans une application asp.net ??

[Jérôme Lambert]

Tout dépend de ce que tu veux récupérer. Est-ce une petite quantité d'information ? Un plus conséquente ?

Pour le 2e cas, je me dirigerais sans hésiter vers le DataSet (dans le acs d'une application ASP.NET) car l'utilisation d'un DataReader risque d'alourdir énormément les traitements.

[SaumonAgile]

Tout dépend de ce que tu veux récupérer. Est-ce une petite quantité d'information ? Un plus conséquente ?

Pour le 2e cas, je me dirigerais sans hésiter vers le DataSet (dans le acs d'une application ASP.NET) car l'utilisation d'un DataReader risque d'alourdir énormément les traitements.

C'est surprenant, j'aurais dit exactement l'inverse, mais dans certains cas seulement. Je suis d'accord pour le DataSet quand le volume de données est modéré. Pour des grosses tables, l'empreinte mémoire d'un DataSet est à mon goût trop importante, dans ce cas, j'opterais plutot pour un DataReader.

[lutecefalco]

Faudrait aussi savoir si tu souhaites juste lire les données ou alors faire un binding bidirectionnel.
Car je suis pas sûr qu'un DataReader le permette (à vérifier qd même )

[Jarodtweiss]

Histoire d'alimenter le débat:

Tout d'abord, il faut bien voir les différences :
DataReader

• Travaille en mode connecté (la connexion à la DB ne sera relâché que lors de Close du DataReader)
• En mode "forward only" --> Une fois accéder à la ligne 1, tu ne peux plus revenir en arrière
• Terriblement léger

DataSet

• Travaille en mode déconnecté : va charger toutes les données côté serveur et va relâcher la connexion immédiatement (d'ailleurs, ce n'est pas toi qui la gère)
• Accès à n'importe quel donnée à n'importe quel moment
• Evidemment beaucoup plus lourd en mémoire, d'autant plus que ton dataset va mémoriser plusieurs versions de tes lignes afin de pouvoir "comitter" ou "rollbacker" tes modifications

Bref, ça dépend beaucoup beaucoup de l'utilisation que tu veux faire.
Mon credo est de dire: jamais de dataset pour rapatrier une seule ligne, c'est trop lourd et n'apporte rien. Il ne doit être utilisé que, à mon sens, dans les conditions suivantes

• Besoin de rapatrier bcp de données (libérons les connexions au plus vite)
• Besoin de rapatrier plusieurs tables d'un coup pour faire des séries de "join" côté .NET
• Besoin de manipuler les données (rowfilter, sort, ...)

Notez enfin que la réponse souvent donnée (je cite) "le dataset c'est mieux, parce que ça permet de faire des datasets typés et donc on n'hardcode pas le nom des champs de la DB et on n'a pas besoin de passer par la position du champs retournée" est nulle et non avenue:

• Le dataset typé hardcode évidemment lui-même le nom des champs. Si cela peut être intéressant à des fins de lisibilité, ce n'est pas un avantage en soi sur le datareader (on peut créer notre propre classe de constantes par exemple)
• On n'est pas obligé de passer par la position du champs avec un DataReader. Il possède aussi une méthode (dont le nom m'échappe. GetOrdinal je crois) qui nous permet de travailler avec le nom

Qu'en pensez-vous ?

[tomlev]

On n'est pas obligé de passer par la position du champs avec un DataReader. Il possède aussi une méthode (dont le nom m'échappe. GetOrdinal je crois) qui nous permet de travailler avec le nom

Pas la peine d'utiliser GetOrdinal non plus...

Code :

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

1
2
3
4
 
DataReader dr;
...
string s = (string) dr["nom_du_champ"];