Lequel utliser ,un dataset ou un dataredear dans une application asp.net ??
Version imprimable
Lequel utliser ,un dataset ou un dataredear dans une application asp.net ??
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.
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 :mrgreen:)
Histoire d'alimenter le débat: :lol:
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 ?
Pas la peine d'utiliser GetOrdinal non plus...Citation:
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
Code:
1
2
3
4 DataReader dr; ... string s = (string) dr["nom_du_champ"];
Oui exact.
En fait je travaille toujours avec l'Enterprise Library et donc avec des IDataReader (ce que je ne saurais que trop recommander d'ailleurs !!)
Et l'interface ne nous permet pas de passer directement avec le nom
Est-ce qu’on peut utiliser le mode connecté et le mode déconnecté sur la même page asp.net ??bon niveau programmation ça marche ,mais niveau performance …
Pour l'enterprise Library tu peux créer des methodes d'accès selon le nom comme ca :
apres il te suffit d'appeler les methodes :Code:
1
2
3
4
5
6
7
8
9 public string GetString(IDataReader reader, string col) { int numcol = reader.GetOrdinal(col); if (reader.IsDBNull(numcol)) return null; else return reader.GetString(numcol); }
Code:
1
2 string result = GetString(reader,"libele");
Oui tout à fait, c'est ce qu'on fait en interne