J'ai débuté il y a quelques mois en VB.NET et je commence à réaliser une
application qui utilise des bases de données Access comme support de données
et je les exploite par le code avec ADO.NET.
Mon application avance, et j'utilise un DATASET dans lequel je charge les
tables nécessaires à l'édition au fur et à mesure de la demande utilisateur.
Tout va bien. Pour l'instant la base de données est presque vide.
La question stratégique que je me pose est :
Lorsque les tables auront un volume "de croisière", est-ce que ma stratégie
d'avoir toujours un objet DATASET en mémoire ne va pas poser un problème de
ressources mémoire à un moment ?
Est-ce un bon principe de maintenir un objet DATASET "sous la main" partout
dans l'application ?
Ou est-ce qu'un DATASET est plutôt voué à être instancié, utilisé, puis
déposé ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Poyo
Bonjour,
ca c'est l'éternelle question et ca dépend de ta problématique.
premièrement, que ta table dispose d'un gros volume de données ou pas, prend bien l'habitude à ne charger que ce dont tu as besoin. Ensuite c'est quelle genre de table, si c'est une table qui bouge quasiment pas, que tu n'accèdes généralement qu'en lecture, la gestion d'un cache est peut être intéressant. Est-ce une application mono ou multi utilisateur. si c'est du multi, attention aux verrous sur les données, il faut donc les libérers avec les éventuelles mises à jour au plus tôt. ensuite c'est le problème des performances, conserver beaucoup de données en mémoire ? ou alors les lires 150 fois ?
par contre pour l'usage même du dataset dans l'application, perso, je suis plutôt pour lire en base un dataset (ou datareader) et mettre le résultat dans un objet, ou une liste d'objet. en gros, si tu as une table personne, tu fait une classes personne disposant des mêmes propriétés que ta table. la méthode qui se charge de lires des données de la table personne transforme le dataset chargés en liste d'objets personne. Mais bon cela ne répond pas a ta question :), ca ne changera pas l'histoire de la durée de vie de tes données au sein de l'application.
"Jean-Noël" a écrit dans le message de news:uK01%
Bonjour,
J'ai débuté il y a quelques mois en VB.NET et je commence à réaliser une application qui utilise des bases de données Access comme support de données et je les exploite par le code avec ADO.NET.
Mon application avance, et j'utilise un DATASET dans lequel je charge les tables nécessaires à l'édition au fur et à mesure de la demande utilisateur. Tout va bien. Pour l'instant la base de données est presque vide.
La question stratégique que je me pose est : Lorsque les tables auront un volume "de croisière", est-ce que ma stratégie d'avoir toujours un objet DATASET en mémoire ne va pas poser un problème de ressources mémoire à un moment ? Est-ce un bon principe de maintenir un objet DATASET "sous la main" partout dans l'application ? Ou est-ce qu'un DATASET est plutôt voué à être instancié, utilisé, puis déposé ?
Merci de vos conseils. Jean-Noël.
Bonjour,
ca c'est l'éternelle question et ca dépend de ta problématique.
premièrement, que ta table dispose d'un gros volume de données ou pas, prend
bien l'habitude à ne charger que ce dont tu as besoin.
Ensuite c'est quelle genre de table, si c'est une table qui bouge quasiment
pas, que tu n'accèdes généralement qu'en lecture, la gestion d'un cache est
peut être intéressant.
Est-ce une application mono ou multi utilisateur. si c'est du multi,
attention aux verrous sur les données, il faut donc les libérers avec les
éventuelles mises à jour au plus tôt.
ensuite c'est le problème des performances, conserver beaucoup de données en
mémoire ? ou alors les lires 150 fois ?
par contre pour l'usage même du dataset dans l'application, perso, je suis
plutôt pour lire en base un dataset (ou datareader) et mettre le résultat
dans un objet, ou une liste d'objet. en gros, si tu as une table personne,
tu fait une classes personne disposant des mêmes propriétés que ta table. la
méthode qui se charge de lires des données de la table personne transforme
le dataset chargés en liste d'objets personne. Mais bon cela ne répond pas a
ta question :), ca ne changera pas l'histoire de la durée de vie de tes
données au sein de l'application.
"Jean-Noël" <jean-noel.falquet@wanadoo.fr> a écrit dans le message de
news:uK01%23f42IHA.5024@TK2MSFTNGP03.phx.gbl...
Bonjour,
J'ai débuté il y a quelques mois en VB.NET et je commence à réaliser une
application qui utilise des bases de données Access comme support de
données et je les exploite par le code avec ADO.NET.
Mon application avance, et j'utilise un DATASET dans lequel je charge les
tables nécessaires à l'édition au fur et à mesure de la demande
utilisateur. Tout va bien. Pour l'instant la base de données est presque
vide.
La question stratégique que je me pose est :
Lorsque les tables auront un volume "de croisière", est-ce que ma
stratégie d'avoir toujours un objet DATASET en mémoire ne va pas poser un
problème de ressources mémoire à un moment ?
Est-ce un bon principe de maintenir un objet DATASET "sous la main"
partout dans l'application ?
Ou est-ce qu'un DATASET est plutôt voué à être instancié, utilisé, puis
déposé ?
ca c'est l'éternelle question et ca dépend de ta problématique.
premièrement, que ta table dispose d'un gros volume de données ou pas, prend bien l'habitude à ne charger que ce dont tu as besoin. Ensuite c'est quelle genre de table, si c'est une table qui bouge quasiment pas, que tu n'accèdes généralement qu'en lecture, la gestion d'un cache est peut être intéressant. Est-ce une application mono ou multi utilisateur. si c'est du multi, attention aux verrous sur les données, il faut donc les libérers avec les éventuelles mises à jour au plus tôt. ensuite c'est le problème des performances, conserver beaucoup de données en mémoire ? ou alors les lires 150 fois ?
par contre pour l'usage même du dataset dans l'application, perso, je suis plutôt pour lire en base un dataset (ou datareader) et mettre le résultat dans un objet, ou une liste d'objet. en gros, si tu as une table personne, tu fait une classes personne disposant des mêmes propriétés que ta table. la méthode qui se charge de lires des données de la table personne transforme le dataset chargés en liste d'objets personne. Mais bon cela ne répond pas a ta question :), ca ne changera pas l'histoire de la durée de vie de tes données au sein de l'application.
"Jean-Noël" a écrit dans le message de news:uK01%
Bonjour,
J'ai débuté il y a quelques mois en VB.NET et je commence à réaliser une application qui utilise des bases de données Access comme support de données et je les exploite par le code avec ADO.NET.
Mon application avance, et j'utilise un DATASET dans lequel je charge les tables nécessaires à l'édition au fur et à mesure de la demande utilisateur. Tout va bien. Pour l'instant la base de données est presque vide.
La question stratégique que je me pose est : Lorsque les tables auront un volume "de croisière", est-ce que ma stratégie d'avoir toujours un objet DATASET en mémoire ne va pas poser un problème de ressources mémoire à un moment ? Est-ce un bon principe de maintenir un objet DATASET "sous la main" partout dans l'application ? Ou est-ce qu'un DATASET est plutôt voué à être instancié, utilisé, puis déposé ?
Merci de vos conseils. Jean-Noël.
Michel LEVY
Bonjour,
si ton application est centrée sur les données, je te conseille de t'appuyer sur un framework "data-centric" : CSLA, Vanatec OA, ou StrataFrame (le top du top à mon avis, c'est celui que j'utilise)
-- Michel -- "Jean-Noël" a écrit dans le message de news: uK01%
Bonjour,
J'ai débuté il y a quelques mois en VB.NET et je commence à réaliser une application qui utilise des bases de données Access comme support de données et je les exploite par le code avec ADO.NET.
Mon application avance, et j'utilise un DATASET dans lequel je charge les tables nécessaires à l'édition au fur et à mesure de la demande utilisateur. Tout va bien. Pour l'instant la base de données est presque vide.
La question stratégique que je me pose est : Lorsque les tables auront un volume "de croisière", est-ce que ma stratégie d'avoir toujours un objet DATASET en mémoire ne va pas poser un problème de ressources mémoire à un moment ? Est-ce un bon principe de maintenir un objet DATASET "sous la main" partout dans l'application ? Ou est-ce qu'un DATASET est plutôt voué à être instancié, utilisé, puis déposé ?
Merci de vos conseils. Jean-Noël.
Bonjour,
si ton application est centrée sur les données, je te conseille de t'appuyer
sur un framework "data-centric" : CSLA, Vanatec OA, ou StrataFrame (le top
du top à mon avis, c'est celui que j'utilise)
--
Michel
--
"Jean-Noël" <jean-noel.falquet@wanadoo.fr> a écrit dans le message de news:
uK01%23f42IHA.5024@TK2MSFTNGP03.phx.gbl...
Bonjour,
J'ai débuté il y a quelques mois en VB.NET et je commence à réaliser une
application qui utilise des bases de données Access comme support de
données et je les exploite par le code avec ADO.NET.
Mon application avance, et j'utilise un DATASET dans lequel je charge les
tables nécessaires à l'édition au fur et à mesure de la demande
utilisateur. Tout va bien. Pour l'instant la base de données est presque
vide.
La question stratégique que je me pose est :
Lorsque les tables auront un volume "de croisière", est-ce que ma
stratégie d'avoir toujours un objet DATASET en mémoire ne va pas poser un
problème de ressources mémoire à un moment ?
Est-ce un bon principe de maintenir un objet DATASET "sous la main"
partout dans l'application ?
Ou est-ce qu'un DATASET est plutôt voué à être instancié, utilisé, puis
déposé ?
si ton application est centrée sur les données, je te conseille de t'appuyer sur un framework "data-centric" : CSLA, Vanatec OA, ou StrataFrame (le top du top à mon avis, c'est celui que j'utilise)
-- Michel -- "Jean-Noël" a écrit dans le message de news: uK01%
Bonjour,
J'ai débuté il y a quelques mois en VB.NET et je commence à réaliser une application qui utilise des bases de données Access comme support de données et je les exploite par le code avec ADO.NET.
Mon application avance, et j'utilise un DATASET dans lequel je charge les tables nécessaires à l'édition au fur et à mesure de la demande utilisateur. Tout va bien. Pour l'instant la base de données est presque vide.
La question stratégique que je me pose est : Lorsque les tables auront un volume "de croisière", est-ce que ma stratégie d'avoir toujours un objet DATASET en mémoire ne va pas poser un problème de ressources mémoire à un moment ? Est-ce un bon principe de maintenir un objet DATASET "sous la main" partout dans l'application ? Ou est-ce qu'un DATASET est plutôt voué à être instancié, utilisé, puis déposé ?
