Utilisation de la base de données pour conserver les paramètres de l'application

Question

Je cherche des moyens de rendre notre application plus extensible et plus facile à manipuler sans avoir à modifier le fichier web.config (ou, dans notre cas, les fichiers application.config, qui contiennent le noeud appsettings).

L’une des solutions auxquelles j’ai pensé est de conserver les paramètres de l’application dans la table de base de données qui a une dépendance sqlcached. Cela signifie que:

• Chaque fois qu'un paramètre est modifié dans la base de données, le cache est invalidé et les paramètres sont à nouveau récupérés, ce qui permet de mettre à jour l'application en temps réel sans avoir à modifier les fichiers et à redémarrer l'ensemble de l'application.
• Nous pouvons créer un outil personnalisé nous permettant de modifier les paramètres.

Selon moi, les inconvénients sont que cela peut entraîner de graves problèmes de logique. Si vous contrôlez le paramétrage d'une application au début d'un processus et que celui-ci change ensuite à mi-parcours, vous risquez de modifier involontairement le processus. flux, car l'exigence d'un redémarrage complet de l'application est supprimée.

Y a-t-il un moyen de contourner cela?

Existe-t-il un meilleur moyen de gérer les paramètres d'applications, afin de pouvoir les modifier à la volée à distance pour un, plusieurs ou tous les serveurs à la fois?

Answer 1

Je pense que vous avez cloué les deux principaux acteurs:

• soit vous avez accès au système de fichiers et vous mettez tous vos paramètres dans une pléthore de fichiers * .config

OU:

• vous n’avez pas accès (ou seulement un accès très limité) au système de fichiers du serveur; il est donc probablement préférable de placer les paramètres de configuration et les préférences de l’utilisateur dans une base de données, en ne laissant en principe que la chaîne de connexion au fichier de configuration. sur le disque

Les deux approches ont leurs avantages et leurs inconvénients. Cela fait longtemps que j'essaie de trouver un moyen de "matérialiser" une section de configuration d'un champ de base de données, afin que je puisse fondamentalement utiliser le XML de configuration, mais stocké dans un champ de base de données. Malheureusement, l’ensemble du système de configuration .NET 2.0 est en grande partie "verrouillé". et suppose seulement que les données proviendront de fichiers - il n’ya aucun moyen de les connecter, par exemple. un fournisseur de base de données permettant au système de configuration de lire son contenu depuis un champ de base de données :-( vraiment dommage!

La seule autre approche que j'ai vue est un "ConfigurationService". dans exemple d'application StockTrader 2.0 fourni par Microsoft, mais pour mes besoins , c’était trop, un sous-système très complexe et très lourd.

Answer 2

Vous pouvez utiliser SQLite, qui sera une base de données autonome dans un seul fichier. Deux oiseaux avec une pierre?

Answer 3

Si vous faites référence à un fichier de configuration externe contenant des paramètres d'applications (en laissant tout le reste dans le fichier app.config normal), alors je pense que le modifier ne recharge que ces paramètres, cela ne force pas le redémarrage complet de l'application.

Il y a une question similaire sur le sujet ici: fichiers app.config (web.config) imbriqués

Le problème de la modification des valeurs en cours d’exécution du programme, vous pouvez le localiser localement et créer un événement lorsqu’il change, ce qui permet aux routines d’atteindre un point approprié avant d’utiliser les valeurs mises à jour.

Je pense que dans asp.net, nous l’obtenons gratuitement, car chaque cycle de vie de page est distinct, de sorte que la valeur est simplement appliquée aux nouvelles demandes de page uniquement, et non au milieu d’une exécution.

Modifier: quelques infos supplémentaires:

Des modifications de configuration entraînent un redémarrage du domaine d'application

De MSDN :

  

Les modifications apportées aux paramètres de configuration dans les fichiers Web.config entraînent indirectement le redémarrage du domaine d'application. Ce problème se produit par conception. Vous pouvez éventuellement utiliser l'attribut configSource pour référencer des fichiers de configuration externes qui ne provoquent pas de redémarrage lorsqu'une modification est apportée. Pour plus d'informations, voir configSource dans Attributs généraux hérités par éléments de section.

Plus d'informations sur la classe ConfigurationManager dans l'espace de nom System.Configuration pouvant être utilisé pour modifier le configurer les fichiers par programme (par exemple, dans un outil personnalisé, si des autorisations de lecture de disque appropriées peuvent être fournies). Si vous vous en tenez à utiliser les classes de configuration intégrées, je pense que changer les configurations externes ne provoquerait pas de redémarrage de l'application, mais déclencherait des événements (tels que propriété modifiée ) que vous pouvez gérer afin d’assurer que votre code ne soit pas surpris par la modification des paramètres.