10
votes

Comment créeriez-vous la configuration centralisée sur plusieurs projets?

J'ai une solution avec environ 10 projets avec une configuration en lecture seule. Ce sont des applications Web, des services Windows, des applications de console, etc. Tous les projets, à l'exception de celui-ci figurant sur le même serveur. Chaque projet dispose de 3 environnements - Dev, test et production. Donc, il y a 30 ensembles de configuration différents, chacun avec un nombre décent de paramètres. Il est lourde pour garder la configuration cohérente sur chaque application et chaque environnement.

J'ai remarqué que la majeure partie de la configuration est courante sur chaque projet, alors 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 peut-être qu'une bibliothèque contenant une classe statique codée dur pourrait réellement fonctionner correctement - bien de devoir compiler pour changer de configuration. Idéalement, la configuration devrait sortir d'un fichier .config.

Comment alliez-vous centraliser la configuration pour plusieurs projets?


0 commentaires

4 Réponses :


2
votes

Vous pouvez certainement configurer un service WCF qui a une opération simple pour récupérer les paramètres de configuration, prendre l'application et l'environnement en tant que paramètre; Vous pouvez alors avoir le service charger la configuration correcte à partir d'un fichier et le renvoyer à l'appelant. Il est peut-être une bonne idée de faire des fichiers de configuration imbriqués, de sorte que les paramètres communs ne soient définis qu'une fois au niveau le plus générique.

Un problème potentiel pourrait survenir si le service WCF est en panne lors du démarrage de l'une de vos applications - vous devrez décider s'il y a une configuration / mise en cache par défaut de la copie précédente pour cette situation, ou si vous ne le faites tout simplement pas Autoriser les applications à démarrer s'ils ne peuvent pas se connecter.

Une autre chose à considérer est l'avantage des fichiers .config dans .net dans ce que lorsqu'ils changent l'application peuvent répondre; Vous voudrez peut-être avoir un service de rappel WCF qui notifie les clients si leur configuration a été mise à jour sur le serveur central, elle peut donc en demander une nouvelle copie et se mettre à jour si nécessaire.


1 commentaires

Vous avez soulevé des choses que je n'avais pas de choses avec l'approche de la WCF. J'ai suscité votre réponse.



1
votes

Comme ils sont (presque) tous sur le même serveur, vous pouvez envisager de fournir des valeurs par défaut dans le Machine.Config et / ou Central web.config fichiers. Je ne suis normalement pas un fan d'utiliser / changer ces fichiers, mais ils sont là ... dans \ windows \ micsrosoft.net \ framework \ config \


1 commentaires

Pas une mauvaise option. Si je possédais les serveurs, j'utiliserais machine.config. Je suis à un grand org et nous essayons de garder le serveur se développe vraiment simple.



12
votes

Si vous souhaitez conserver l'interface de configuration standard, jetez un coup d'œil au protégéConfigurationProvider . Ce fournisseur vous permet de stocker vos données de configuration en dehors d'un fichier de configuration standard, de la chiffrer à votre guise ou de rediriger les demandes de configuration de la manière que vous voyez en forme:


1 commentaires

Je me souviens de cela de quelque part;) bonne réponse!



0
votes

Vous pouvez utiliser une configuration centralisée sévère comme Lygeum qui permet de gérer les applications et les environnements via Web Interface de ligne de la console ou de commande avec le module de gestion de l'utilisateur et de gestion des clients, les clients peuvent figurer dans vos applications Web, services de console ou autre. L'installation du serveur est simple via Docker.


0 commentaires