Comment puis-je gérer la configuration de l'application dans ASP.NET?

Question

J'éprouve des difficultés à gérer la configuration d'une application ASP.Net à déployer pour différents clients. Le volume des différents paramètres qui ont besoin de bidouilles prend beaucoup de temps, et les méthodes de configuration actuelles sont trop compliquées pour nous permettre de pousser cette responsabilité aux partenaires de soutien.

Toutes les suggestions de meilleures méthodes pour gérer ceci ou de bonnes sources d'information pour la recherche?

Comment nous faisons les choses à l'heure actuelle:

• Divers fichiers de configuration xml qui sont référencés dans web.config, par exemple un AppSettings.xml.
• Configurations pour des sites spécifiques sont conservés dans les fichiers de configuration en double.
• Les fichiers texte contenant des listes de données spécifiques au site
• Dans certains cas, les modifications manuelles ponctuelles à la base de données
• C # configuration de Windsor du CIO.

Les problèmes spécifiques que nous rencontrons:

• Différents sites avec des caractéristiques différentes ont permis, différents services externes, nous devons parler et différentes règles métier.
• Différents types de déploiement (live, test, formation)
• Touches de configuration changent suivant les versions (sont ajoutés, supprimer), ce qui signifie que nous devons mettre à jour tous les fichiers en double
• Nous devons toujours être en mesure de modifier les touches lorsque l'application est en cours d'exécution

Nos pensées actuelles sur la façon dont nous pourrions aborder ce sont les suivants:

• Déplacer la configuration dans le code compilé dynamiquement (éventuellement Boo, Binsor ou JavaScript)
• Avoir une certaine forme de diffing / configuration fusion: combiner une configuration par défaut avec un live / test / config de formation et une configuration spécifique au site

Answer 1

Quelle que soit la façon dont vous allez, je pense qu'il pourrait être utile d'avoir la notion d'une seule « source de vérité » pour votre configuration.

Duplication est très bien, si vous devez fournir une configuration à certains composants dans leur propre forme spécialisée.

Mais pour conserver votre santé mentale, je pense que vous devriez essayer de viser d'avoir un endroit où vous définissez toute la configuration se rapportant à votre application, puis un mécanisme bien défini pour la traduction qui en entrées à l'intérieur Web.config, et tout autre mécanisme de configuration que vous devez soutenir.

En fonction du niveau de compétence de vos partenaires de soutien (ou non ils casseront XML), je suppose que vous pouvez également fournir un utilitaire GUI pour leur faire tournoyer tous les boutons dans ce fichier de configuration « source de vérité » , avec « Appliquer » en cours et en cours d'exécution de transformation / code de mise à jour pour apporter les modifications nécessaires à Web.config et amis.

Ensuite, pour gérer votre configuration pour différents sites / clients, vous avez théoriquement autour d'un pour gérer le fichier de configuration.

Remarque: Dans ASP.NET 4.0 transformer une configuration accumulation de temps mécanisme sera disponible (voir http://blog.hmobius.com/post/2010/02/17/ASPNET-40-Part-4 -config-transformation-Files.aspx ), ce qui peut rendre cette tâche plus facile. Il semble que vous pouvez l'utiliser avec des hacks pour des projets non web (voir http://philbolduc.blogspot.com/2010/03/using-config-transforms-outside-web.html ).

Cependant, si vous avez besoin de faire ces changements au moment du déploiement, vous pouvez être coincé avec des outils personnalisés d'écriture pour ce faire, mais il semble que les transformations de XDT peut être le chemin à parcourir pour vous, étant donné que vous voulez être en mesure pour ajouter / mise à jour / supprimer des éléments.

Answer 2

Si le code en utilisant lesdits éléments de configuration est le code que vous gérez / peut changer (et tous en cours d'exécution dans l'espace de code managé / C #) Je regarderais au portage des appels de méthode qui obtiennent les paramètres d'un appel dans une classe comme singleton avec au moins un procédé GetString () sur elle.

GetObject () peut être très utile (consultez les trucs de sérialisation XML .Net - les Américains l'orthographier avec un « z »: sérialisation) ... utile pour beaucoup de choses, mais aussi parce que cela signifie que vous pouvez commencer l'emballage connexes les éléments de configuration dans des entrées uniques dans le magasin.

En ce qui concerne l'utilisation d'un seul magasin (une table de base de données avec accès mises en cache) ou utilisez votre nouvelle articles façade seulement pour encapsuler où la configuration de configuration sont stockés - c'est à vous ... Je préfère fortement un seul magasin par le déploiement de produits pour configuration, car vous savez toujours exactement où chercher et où faire des changements. Toutes les références de service Web (WCF ou autre) peuvent être constucted et appelées à l'aide des chaînes fournies runtime ...:)

En termes de valeurs de mise en cache des clés - j'utiliser mon propre dans le cache de mémoire (pour les petites applications) car la surcharge sur la pile est facile à gérer ... des choses comme memcache pourraient travailler ici (magasin de configuration est accessible via TCP / sur la réseau quelque part) ...

EDIT Quelque chose comme:

public class ConfigurationStore
{
    private static ConfigurationStore _instance = null;

    public static ConfigurationStore Instance {
        get {
        if(_instance == null)
        {
            _instance = new ConfigurationStore();
        }

        return _instance;
        }
    }

    public string GetValue(string key)
    {
        ....
    }

    public Object GetObject(string key)
    {
        ...
    }
}

Answer 3

Vous pouvez envisager de regarder des scripts NAnt pour l'automatisation combinée avec un peu utilitaire .net personnalisé pour manipuler les clés de configuration.