Combien d'objets DataTable dois-je utiliser dans mon application C #?

Question

Je suis un programmeur expérimenté dans un outil de développement hérité (mais orienté objet) et en passant à C # /. Net. J'écris une petite application mono-utilisateur utilisant SQL Server CE 3.5. J'ai lu le DataSet conceptuel et la documentation associée et mon code fonctionne.

Maintenant, je veux m'assurer que je le fais "bien", que je reçois les commentaires de codeurs .Net / SQL Server expérimentés, du genre que vous n'obtenez pas en lisant le document.

J'ai remarqué que j'ai un code comme celui-ci à quelques endroits:

var myTableDataTable = new MyDataSet.MyTableDataTable();
myTableTableAdapter.Fill(MyTableDataTable);

... // other code

Dans une application à utilisateur unique, effectuez-vous généralement cette opération une seule fois au démarrage de l'application, instanciez un objet DataTable pour chaque table, puis stockez-y une référence afin que vous n'utilisiez jamais cet objet unique déjà rempli de données. De cette façon, vous ne liriez les données de la base qu'une seule fois au lieu de plusieurs fois. Ou est-ce que les frais généraux de ce travail sont si faibles qu’ils n’ont aucune importance (cela pourrait aussi être contre-productif avec de grandes tables)?

Answer 1

Pour CE, c'est probablement pas un problème. Si vous étiez en train de pousser cette application vers des milliers d'utilisateurs et qu'ils utilisaient tous une base de données centralisée, vous souhaiterez peut-être consacrer un peu de temps à l'optimisation. Dans une base de données d'instance mono-utilisateur telle que CE, à moins que des données indiquent que vous devez optimiser, je ne perdrais pas de temps à vous en préoccuper. Optimisation prématurée, etc.

Answer 2

La façon de décider varie entre 2 choses principales 1. Les données vont-elles être consultées en permanence 2. Y a-t-il beaucoup de données

Si vous utilisez constamment les données des tableaux, chargez-les lors de la première utilisation. Si vous utilisez occasionnellement les données, remplissez le tableau lorsque vous en avez besoin, puis supprimez-le.

Par exemple, si vous avez 10 écrans d'interface graphique et utilisez uniquement myTableDataTable sur l'un d'entre eux, lisez-le uniquement sur cet écran.

Answer 3

Le choix ne dépend pas vraiment de C # lui-même. Cela revient à un équilibre entre:

1. À quelle fréquence utilisez-vous les données de votre code?
2. Les données changent-elles (et vous en souciez-vous?)
3. Quel est le coût (en temps) relatif à la récupération des données, par rapport à tout ce que votre code génère?
4. Quelle valeur accordez-vous à la performance par rapport à l'effort / le temps du développeur (pour cette application particulière)?

En règle générale: pour les applications de production, où les données ne changent pas souvent, je créerais probablement le DataTable une fois, puis conserverais la référence que vous avez mentionnée. Je souhaiterais également envisager de placer les données dans une collection / liste / dictionnaire typé, au lieu de la classe générique DataTable, voire rien d'autre, car il est plus facile de laisser le compilateur corriger ses erreurs de frappe.

Pour un utilitaire simple que vous exécutez vous-même et qui commence, fait son travail et se termine, cela ne vaut probablement pas la peine.

Vous parlez de Windows CE. Dans ce cas particulier, je ferais très probablement la requête une seule fois et conserverais les résultats. Les systèmes d'exploitation mobiles ont des contraintes supplémentaires en termes de batteries et d'espace que les logiciels de bureau n'ont pas. Fondamentalement, un système d’exploitation mobile rend la puce n ° 4 beaucoup plus importante.

Chaque fois que vous ajoutez un autre appel de récupération à partir de SQL, vous appelez plus souvent des bibliothèques externes, ce qui signifie que vous exécutez probablement plus de temps, allouant et libérant plus de mémoire plus souvent (ce qui ajoute la fragmentation) et peut éventuellement provoquer la restauration de la base de données. -lire de la mémoire flash. il est probablement préférable de conserver les données une fois que vous les avez, en supposant que vous le puissiez (voir puce # 2).

Answer 4

Il est plus facile de trouver la réponse à cette question lorsque vous pensez que les jeux de données constituent une "session". de données. Vous remplissez les jeux de données; vous travaillez avec eux et ensuite vous remettez les données ou les jetez lorsque vous avez terminé. Vous devez donc poser des questions comme celle-ci:

1. Les données doivent-elles être à jour? Avez-vous toujours besoin des dernières informations ou la base de données ne sera-t-elle pas modifiée aussi fréquemment?
2. Pour quoi utilisez-vous les données? Si vous ne l'utilisez que pour des rapports, vous pouvez facilement remplir un jeu de données, exécuter votre rapport, puis jeter le jeu de données et la prochaine fois seulement. faire un nouveau. Cela vous donnera quand même plus de données actuelles.
3. De combien de données s'agit-il exactement? Vous avez dit que vous travailliez avec un ensemble de données relativement petit. Il n'y a donc pas d'impact majeur sur la mémoire si vous la stockez entièrement en mémoire et la conservez. là pour toujours.

Puisque vous dites que c'est une application mono-utilisateur sans beaucoup de données, je pense que vous êtes sûr de tout charger au début, de l'utiliser dans vos jeux de données, puis de le mettre à jour à la fermeture.

La principale chose à laquelle vous devez vous intéresser dans ce scénario est la suivante: que se passera-t-il si l'application se ferme anormalement, en raison d'un crash, d'une panne de courant, etc.? L'utilisateur va-t-il perdre tout son travail? Mais il se trouve que les séries de données sont extrêmement faciles à sérialiser. Vous pouvez donc assez facilement implémenter un "enregistrement de temps en temps". procédure pour sérialiser le contenu du jeu de données sur le disque afin que l'utilisateur ne perde pas beaucoup de travail.