Question

Je prévois de stocker tous mes paramètres de configuration dans la section app.config de mon application (en utilisant le ConfigurationManager.AppSettings classe).Au fur et à mesure que l'utilisateur modifie les paramètres à l'aide de l'interface utilisateur de l'application (en cliquant sur des cases à cocher, en choisissant des boutons radio, etc.), je prévois d'écrire ces modifications dans le AppSettings.En même temps, pendant que le programme est en cours d'exécution, je prévois d'accéder au AppSettings constamment à partir d’un processus qui traitera constamment des données.Les modifications apportées aux paramètres via l'interface utilisateur doivent affecter le traitement des données en temps réel, c'est pourquoi le processus accédera au AppSettings en permanence.

Est-ce une bonne idée en termes de performances ?En utilisant AppSettings est censé être "la bonne façon" de stocker et d'accéder aux paramètres de configuration lors de l'écriture d'applications .Net, mais je crains que cette méthode n'était pas destinée à une charge constante (au moins en termes de paramètres constamment lus).

Si quelqu'un a une expérience dans ce domaine, j'apprécierais grandement sa contribution.

Mise à jour: Je devrais probablement clarifier quelques points.

Il ne s'agit pas d'une application Web, donc connecter une base de données à l'application peut s'avérer excessif simplement pour stocker les paramètres de configuration.Il s'agit d'une application Windows Forms.

Selon la documentation MSDN, le ConfigurationManager sert à stocker non seulement les paramètres au niveau de l'application, mais également les paramètres utilisateur.(Particulièrement important si, par exemple, l'application est installée en tant qu'application à confiance partielle.)

Mise à jour 2 : J'ai accepté la réponse de Lomaxx parce que Properties cela ressemble en effet à une bonne solution, sans avoir à ajouter de couches supplémentaires à mon application (comme une base de données).Lors de l'utilisation des propriétés, il effectue déjà toute la mise en cache suggérée par d'autres.Cela signifie que toutes les modifications et lectures ultérieures sont toutes effectuées en mémoire, ce qui rend le processus extrêmement rapide.Properties n'écrit les modifications sur le disque que lorsque vous le lui demandez explicitement.Cela signifie que je peux apporter des modifications aux paramètres de configuration à la volée au moment de l'exécution, puis effectuer une sauvegarde finale sur le disque uniquement à la fin du programme.

Juste pour vérifier qu'il serait réellement capable de gérer la charge dont j'ai besoin, j'ai effectué quelques tests sur mon ordinateur portable et j'ai pu effectuer 750 000 lectures et 7 500 écritures par seconde à l'aide des propriétés.C'est bien au-delà de ce que ma candidature permettra jamais je suis même sur le point d'avoir besoin de me sentir assez en sécurité dans l'utilisation des propriétés sans affecter les performances.

Était-ce utile?

La solution

puisque vous utilisez une application Winforms, si elle est dans .net 2.0, il existe en fait un système de paramètres utilisateur (appelé Propriétés) conçu à cet effet. Cet article sur MSDN a une assez bonne introduction à cela

Si vous êtes toujours préoccupé par les performances, jetez un œil à Édition compacte SQL qui est similaire à SQLite mais c'est l'offre Microsoft qui, selon moi, fonctionne très bien avec Winforms et il y a même la possibilité de faites-le fonctionner avec Linq

Autres conseils

Découvrez SQLite, cela semble être une bonne option pour ce scénario particulier.

Dylan,

N'utilisez pas le fichier de configuration de l'application à cette fin, utilisez une base de données SQL (SQLite, MySQL, MSSQL, peu importe) car vous aurez moins à vous soucier des problèmes de concurrence lors des lectures et des écritures dans le fichier de configuration.

Vous bénéficierez également d'une meilleure flexibilité quant au type de données que vous souhaitez stocker.La section appSettings n'est qu'une liste clé/valeur que vous pouvez dépasser avec le temps et à mesure que l'application évolue.Vous pouvez utiliser des sections de configuration personnalisées, mais vous vous retrouvez alors dans un nouveau problème en matière de conception.

Les appSettings ne sont pas vraiment destinés à ce que vous essayez de faire.

Lorsque votre application .NET démarre, elle lit le fichier app.config et met en cache son contenu en mémoire.Pour cette raison, après avoir écrit dans le fichier app.config, vous devrez d'une manière ou d'une autre forcer le runtime à réanalyser le fichier app.config afin qu'il puisse à nouveau mettre en cache les paramètres.C'est inutile

Le meilleure approche serait d'utiliser une base de données pour stocker vos paramètres de configuration.

À moins d'utiliser une base de données, vous pouvez facilement configurer un fichier de configuration XML externe.Lorsque votre application démarre, vous pouvez mettre en cache son contenu dans un objet NameValueCollection ou un objet HashTable.Lorsque vous modifiez/ajoutez des paramètres, vous le ferez sur cette copie mise en cache.Lorsque votre application s'arrête ou à un intervalle de temps approprié, vous pouvez réécrire le contenu du cache dans un fichier.

Quelqu'un me corrige si je me trompe, mais je ne pense pas qu'AppSettings soit généralement destiné à être utilisé pour ce type de paramètres de configuration.Normalement, vous ne définiriez que des paramètres qui restent assez statiques (chaînes de connexion à la base de données, chemins de fichiers, etc.).Si vous souhaitez stocker des paramètres utilisateur personnalisables, il serait préférable de créer un fichier de préférences distinct ou, idéalement, de stocker ces paramètres dans une base de données.

Je n'utiliserais pas de fichiers de configuration pour stocker les données utilisateur.Utilisez une base de données.

Puis-je vous demander pourquoi vous n'enregistrez pas les paramètres de l'utilisateur dans une base de données ?

Généralement, j'enregistre les paramètres de l'application qui sont modifiés très rarement dans la section appSettings (l'adresse e-mail par défaut à laquelle les journaux d'erreurs sont envoyés, le nombre de minutes après lesquelles vous êtes automatiquement déconnecté, etc.). La portée de cela se situe vraiment au niveau de l'application. , pas chez l'utilisateur, et est généralement utilisé pour les paramètres de déploiement.

une chose que j'envisagerais de faire est de mettre en cache les paramètres d'application lors d'une lecture, puis de vider les paramètres du cache lors de l'écriture, ce qui devrait minimiser la quantité de charge réelle que le serveur doit gérer pour traiter les paramètres d'application.

Aussi, si possible, envisagez de diviser les appSettings en configSections afin que vous puissiez lire les paramètres liés à l'écriture et au cache.

Cela dit, j'envisagerais sérieusement d'envisager de stocker ces valeurs dans une base de données, comme vous semblez réellement stocker préférences de l'utilisateur, et non les paramètres de l'application.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top