Discussion :

[Isidore.76]

Bonsoir, ou bonjour, selon l'heure à laquelle vous prendrez connaissance de ce message

Pardon pour l'intitulé du message, mais je n'ai pas trouvé mieux

Ma question est d'ordre général : j'aimerais savoir comment vous travaillez avec une base de données ? Si vous faites usage des datasets, par exemple, est-il possible de faire en sorte qu'une modification dans une grille, un textbox, ou l'item courant d'une liste déroulante impacte automatiquement sur le dataset ? Autrement dit, si vous liez certains (ou tous?) contrôles à un dataset, et qu'ensuite l'utilisateur modifie le contenu d'un contrôle lié, alors est-ce que la modification est répercutée automatiquement sur le dataset ? Ensuite, le dataset peut-il impacter la base de données ? Pareils mécanismes sont possibles dans le cadre d'une application WinForm. Je me pose la question de la faisabilité et de la pertinence de développer avec la même approche dans le cadre d'une application Web. En considérant, peut-être, comme des cas différents une application Web avec AJAX d'une application sans AJAX ? Ou cela ne fait pas de différence ? A vous de me dire

Je suis vivement intéressé par vos avis, retour d'expérience, etc...

A ce jour, j'utilise principalement le DataReader pour récupérer des données de la base... Le dataset n'est pour ainsi dire utilisé qu'au travers du SqlDataSource pour charger un GridView... Et les mises à jour de la base se font par requetes (INSERT, UPDATE, ...) construites "à la main" (pas tout à fait, mais c'est l'idée).

Je suis tout disposé à considérer d'autres approches, et à changer mes habitudes s'il s'avère qu'il y a mieux !

Avis, liens, etc, sont bienvenus !

A vos claviers

[Philippe Vialatte]

Si tu veux mon avis (trés orienté), abandonne les datasets et les datareader, et passe a un orm un peu performant , le gain de temps est non negligeable (pub : surveille la page d'accueil dotnet de DVP dans les semaines a venir)

Sinon, pour les histoires de binding et de dev web, a mon avis, il n'est pas souhaitable d'implementer ce genre de binding...

Si ton idée est d'essayer de tordre le modele web "standard" de requetes et reponses, en faisant par exemple des requetes de mise a jour pour chaque champ (ce que je ne ferais meme pas dans une appli winform, d'ailleurs), tu vas stresser ta base et ton reseau pour rien...

Les echanges Ajax ont un cout, qui peut etre non negligeable, surtout si tu les repete

Alors, aprés, je te dis ca, je ne suis pas Einstein, on a essayé de mettre ce type de solution en place a une époque, et ca à "presque" marché ...mais avec des performances horribles...

[tomlev]

Si tu veux mon avis (trés orienté), abandonne les datasets et les datareader, et passe a un orm un peu performant , le gain de temps est non negligeable (pub : surveille la page d'accueil dotnet de DVP dans les semaines a venir)

C'est vrai qu'aujourd'hui, il est peut-être préférable d'utiliser Linq to Entities ou autre ORM... si on a le choix. Tous les ORM ne supportent pas tous les SGBD, et les DataSets sont encore assez largement utilisés, donc c'est utile de savoir comment ça fonctionne... surtout que c'est assez facile à comprendre.

est-il possible de faire en sorte qu'une modification dans une grille, un textbox, ou l'item courant d'une liste déroulante impacte automatiquement sur le dataset ? Autrement dit, si vous liez certains (ou tous?) contrôles à un dataset, et qu'ensuite l'utilisateur modifie le contenu d'un contrôle lié, alors est-ce que la modification est répercutée automatiquement sur le dataset ?

Oui, le binding est bidirectionnel

Ensuite, le dataset peut-il impacter la base de données ?

Par l'intermédiaire d'un DataAdapter :
http://dotnet.developpez.com/articles/ado2/

Pareils mécanismes sont possibles dans le cadre d'une application WinForm. Je me pose la question de la faisabilité et de la pertinence de développer avec la même approche dans le cadre d'une application Web.

C'est utilisable dans n'importe quel type d'application, Windows ou Web

En considérant, peut-être, comme des cas différents une application Web avec AJAX d'une application sans AJAX ? Ou cela ne fait pas de différence ?

A priori ça ne change rien... à condition de garder le DataSet en cache entre 2 requêtes AJAX, parce que si tu requêtes la base à chaque callback, les perfs risquent d'être calamiteuses


En ce qui me concerne, le choix entre DataSet et DataReader se fait au cas par cas, mais la règle générale que j'applique est la suivante :
- pour des données dont je vais avoir besoin très souvent pendant mes traitements, ou qui doivent rester rapidement disponibles pour être réutilisées plus tard => DataSet
- pour des données "transitoires" dont je n'ai besoin que temporairement => DataReader

Il y a aussi une critère de "fraicheur" des données : attaquer directement la base avec un DataReader donnera des données plus à jour que de lire celle qu'on a mis en cache dans le DataSet (et qui peuvent avoir été modifiées par quelqu'un d'autre entre temps). Donc à voir selon les cas...

Le DataSet est aussi très pratique pour mettre à jour des grandes quantités de données, grâce au DataAdapter

[Philippe Vialatte]

ok, je reprecise ce que je voulais dire avant (le film est fini, ma femme ne rale plus , et j'avais sauté des concepts... )

Pour les ORM: si tu n'est pas dans le cas d'un certain membre de l'équipe de rédaction dont le pseudo commence par un t et se termine par omlev, a savoir forcé d'utiliser une base de données exotique (oui, monsieur, exotique ), tu devrais trouver chaussure a ton pied (en 2.0, NHibernate, Subsonic, llblgen, ou meme mygeneration dans le pire des cas...)

Tous les points de tomlev (nécessité et utilité de connaitre le mecanisme, possibilité de faire du binding bidirectionnel avec les dataset) sont 100% corrects.

Je voulais revenir sur l'aspect "souhaitable" du binding pour une appli web. Une fois que ton dataset est rempli, si tu le stockes en session, ca veut dire :
1- que le contenu du dataset reste dans la memoire du serveur
2- que si le dataset est trop important, tu vas te retrouver dans l'enfer du large object heap, et la, c'est le début de la fin pour le serveur (crash assuré au bout d'un moment, le GC ne désallouant plus la mémoire...pareil, ca nous est *déja* arrivé)

Idéalement, la session ne devrait contenir que très peu d'objets, pour ne pas dégrader les possibilités de montées en charge, et les datasets devraient etre limitées au contexte d'une requete ou d'une réponse, mais pas mis en session...

[lutecefalco]

Moi j'aime bien les DataSets.
On a plein de sites encore en 1.1 et les DataSets sont très utiles pour communiquer des données via des WebServices

[Isidore.76]

Merci pour vos réponses

Je retiens qu'il est parfaitement possible de lier des contrôles à une source de données (dataset par exemple) et que les mises à jour se font dans les deux sens.

Pour fixer d'avantage les idées, supposons une base toute simple avec une table "utilisateur" et une table "profil". Dans la table "utilisateur" on trouve une colonne genre "id_profil" permettant de "faire le lien" entre un utilisateur et un profil. Voilà pour la base. Supposons également une page, toute simple là aussi, avec un formulaire contenant deux textboxs et une liste déroulante : les textboxs servent pour l'affichage et la saisie/modification d'un nom et d'un prénom tandis que la liste déroulante permet la sélection d'un profil.

Corrigez moi si je me trompe, mais coté code nous aurions donc un dataset avec deux datatable : un datatable contenant tous les enregistrements de la table "profil", et un second datatable contenant juste l'enregistrement correspondant à l'utilisateur sur lequel on souhaite travailler ?

Quelque part dans dans le code du Page_Load (*), on lie les contrôles aux datatables. Le chargement des contrôles se fait alors "tout seul". Comment est sélectionné l'item ad'hoc dans la liste des profils ? Comment est sélectionné l'item correspondant au profil de l'utilisateur ?

Imaginons maintenant que l'utilisateur corrige le nom et change le profil, puis la page est "postée" sur le serveur via un bouton "valider". Ce bouton est un contrôle serveur. Dans le code "réagissant" au clic sur le bouton, suffit-il d'une seule instruction pour mettre à jour la base ? Genre MonDataset.UpdateMaBaseSTP() ?

Question : très certainement le dataset doit continuer d'exister sur le serveur entre deux "post" de la page ? Il est mis en cache ? Dans la session ? Dans le cache de l'application ? Dans un "autre lieux" ? Impact sur les performances, la mémoire ? Combien de temps reste-t-il ainsi en cache ? Est-il supprimé de la "zone de cache" uniquement sur demande explicite du développeur (lorsque ce dernier estime qu'il n'en a plus besoin) ? Et/Ou lorsque la session meure ? Comment sont gérés les "conflits" ? Par exemple si dans l'intervalle la base a été modifiée ( le profil a été supprimé, ou l'utilisateur a été modifié par qq'un d'autre, etc...) ? Connaissez-vous un outil simple d'utilisation permettant de connaitre la taille en mémoire du cache de l'application ? La taille en mémoire d'une session ? De toute les sessions ? Peut-être aussi un outil simple pour détecter les fuites mémoires, sachant que j'ai lu ici ou là que cela pouvait arriver...

Enfin, dans tout cela, quel rôle doit ou peut éventuellement jouer le viewstate ?

Beaucoup de questions, j'en ai bien conscience, aussi d'avance un grand MERCI pour toutes les réponses que vous aurez le temps et l'envie de m'apporter !

(*) : par exemple, ce n'est peut-être pas le plus judicieux ?

[Immobilis]

Salut,

Pour ou contre DataSet ou DataReader est une mauvaise question. Il faut plutôt l'aborder en se demandant si tu veux travailler en mode "deconnecté" (de la base de données) ou pas.

• Connecté => DataReader
• Déconnecté => DataSet ou autre.

D'un point de vu performance les <Xxxxx>Reader (Data, Xml, ...) sont beaucoup plus performants (XmlReader est plus performant que XmlDocument). Ils sont rapides, prennent peu de place en RAM.

A+

[tomlev]

Corrigez moi si je me trompe, mais coté code nous aurions donc un dataset avec deux datatable : un datatable contenant tous les enregistrements de la table "profil", et un second datatable contenant juste l'enregistrement correspondant à l'utilisateur sur lequel on souhaite travailler ?

Le second DataTable peut tout à fait contenir tous les utilisateurs, pas forcément seulement celui sur lequel on travaille... évidemment ce n'est pas souhaitable s'il y en a beaucoup

Quelque part dans dans le code du Page_Load (*), on lie les contrôles aux datatables. Le chargement des contrôles se fait alors "tout seul". Comment est sélectionné l'item ad'hoc dans la liste des profils ? Comment est sélectionné l'item correspondant au profil de l'utilisateur ?

Il faut juste que le SelectedValue de la DropDownList soit lié au champ id_profil de l'utilisateur, et que le DataValueField soit "id_profil"

Imaginons maintenant que l'utilisateur corrige le nom et change le profil, puis la page est "postée" sur le serveur via un bouton "valider". Ce bouton est un contrôle serveur. Dans le code "réagissant" au clic sur le bouton, suffit-il d'une seule instruction pour mettre à jour la base ? Genre MonDataset.UpdateMaBaseSTP() ?

On fait ça avec un DataAdapter (cf. mon post précédent)

Question : très certainement le dataset doit continuer d'exister sur le serveur entre deux "post" de la page ? Il est mis en cache ? Dans la session ? Dans le cache de l'application ? Dans un "autre lieux" ? Impact sur les performances, la mémoire ? Combien de temps reste-t-il ainsi en cache ? Est-il supprimé de la "zone de cache" uniquement sur demande explicite du développeur (lorsque ce dernier estime qu'il n'en a plus besoin) ? Et/Ou lorsque la session meure ?

Il n'est pas mis en cache automatiquement, c'est à toi de le faire si tu en as besoin. Tu peux le mettre dans la session, ou au niveau de l'application ou du contexte de la page (Page.Items). C'est aussi à toi de gérer la suppression, puisque c'est toi qui a fait la mise en cache.

Comment sont gérés les "conflits" ? Par exemple si dans l'intervalle la base a été modifiée ( le profil a été supprimé, ou l'utilisateur a été modifié par qq'un d'autre, etc...) ?

Ils ne sont pas gérés... Ce que tu peux faire, si tu as des données en cache dans ton DataSet et que tu veux les "rafraîchir", c'est refaire un dataAdapter.Fill sur ton DataSet : ça importera dans le dataset les lignes nouvellement ajoutées en base, et ça mettra à jour les lignes que tu avais déjà dans le dataset et qui ont été modifiées en base. Par contre je ne pense pas que ça supprime du dataset les lignes supprimées en base...
Pour ce qui est des conflits de mise à jour, une méthode fréquemment utilisée est "optimistic concurrency", qui consiste à vérifier que les valeurs des champs en base correspondent à celles qu'on avait dans le dataset avant modification (dans la clause WHERE de la requête de mise à jour). Par défaut, les UpdateCommand/InsertCommand/DeleteCommand générées par un CommandBuilder incluent ce test.

Enfin, dans tout cela, quel rôle doit ou peut éventuellement jouer le viewstate ?

C'est juste pour conserver des données liées à l'état de la page, mais en aucun cas des quantités importantes de données, car le ViewState est transmis entre le client et le serveur à chaque requête.