Comment pourriez-vous centraliser la configuration sur plusieurs projets?

Question

J'ai une solution avec environ 10 projets avec une configuration en lecture seule. Ce sont des applications Web, des services Windows, des applications console, etc. Tous les projets sauf un sont sur le même serveur. Chaque projet a 3 environnements - dev, test et production. Il y a donc 30 ensembles de configuration différents, chacun avec un nombre décent de paramètres. Il est difficile de garder la configuration cohérente dans toutes les applications et tous les environnements. J'ai remarqué que la plupart de la configuration est commune à chaque projet, donc je pensais qu'il serait bon de centraliser la configuration d'une manière ou d'une autre. J'ai lu quelque part qu'un service WCF pourrait être une bonne approche. Je pensais que peut-être une bibliothèque contenant une classe statique codée en dur pourrait bien fonctionner - malgré avoir à compiler pour modifier la configuration. Idéalement, la configuration devrait provenir d'un fichier .config réel.

Comment voulez-vous centraliser la configuration pour plusieurs projets?

Answer 1

Si vous voulez maintenir l'interface de configuration standard, jetez un oeil à la ProtectedConfigurationProvider. Ce fournisseur vous permet de stocker vos données de configuration en dehors d'un fichier de configuration standard, chiffrer comme bon vous semble, ou rediriger les demandes de configuration de quelque manière que bon vous semble:

• Redirecting Configuration with a Custom Provider - Wrox
• Implementing a Protected Configuration Provider - MSDN
• Protected Configuration - Blayd Software

La beauté de cette approche est que rien ne change dans vos applications existantes. Ils n'ont pas besoin de savoir où leur configuration est stockée. La récupération des données de configuration est isolée dans le fournisseur. Vous pouvez le stocker dans un fichier central, le stocker dans une base de données ou y accéder via un service Web. Si vous changez d'avis, il vous suffit de mettre à jour votre fournisseur. Tout le reste demeure inchangé.

Answer 2

Vous pouvez certainement configurer un service WCF qui a une opération simple pour récupérer les paramètres de configuration, en prenant en compte l'application et l'environnement en tant que paramètre; Vous pouvez alors charger le service dans la configuration correcte d'un fichier et le renvoyer à l'appelant. Cela peut être une bonne idée de faire des fichiers de configuration imbriqués, afin que les paramètres communs ne soient définis qu'une seule fois à leur niveau le plus générique. Un problème potentiel peut survenir si le service WCF est inactif au démarrage de l'une de vos applications. Vous devez décider s'il existe une configuration/mise en cache par défaut de la copie précédente pour cette situation, ou si vous ne l'utilisez pas. t permettre aux applications de démarrer si elles ne peuvent pas se connecter.

Une autre chose à considérer, cependant, est l'avantage des fichiers .config dans .NET en ce sens que lorsqu'ils changent, l'application peut répondre; Vous pouvez avoir un service de rappel WCF qui informe les clients si leur configuration a été mise à jour sur le serveur central, afin qu'ils puissent demander une nouvelle copie et se mettre à jour si nécessaire.

Answer 3

Puisqu'ils sont (presque) tous sur le même serveur, vous pouvez envisager de fournir des valeurs par défaut dans les fichiers machine.config et/ou centraux web.config. Je ne suis généralement pas fan de l'utilisation/modification de ces fichiers, mais ils sont là ... dans \Windows\Micsrosoft.NET\Framework<version>\Config\