Como posso gerenciar a configuração do aplicativo no ASP.NET?

Question

Estou tendo dificuldade em gerenciar a configuração de um aplicativo ASP.NET para implantar para diferentes clientes. O grande volume de configurações diferentes que precisam girar ocupa grandes quantidades de tempo, e os métodos atuais de configuração são muito complicados para nos permitir empurrar essa responsabilidade para apoiar os parceiros.

Alguma sugestão de melhores métodos para lidar com isso ou boas fontes de informação para pesquisar?

Como fazemos as coisas no momento:

• Vários arquivos de configuração XML que são referenciados no web.config, por exemplo, um appSsettings.xml.
• As configurações para sites específicas são mantidas em arquivos de configuração duplicados.
• Arquivos de texto contendo listas de dados específicos para o site
• Em alguns casos, mudanças únicas manuais no banco de dados
• C# Configuração do Windsor IOC.

Os problemas específicos que estamos tendo:

• Sites diferentes com diferentes recursos habilitados, diferentes serviços externos com quem devemos conversar e diferentes regras de negócios.
• Diferentes tipos de implantação (ao vivo, teste, treinamento)
• As teclas de configuração são alteradas entre as versões (seja adicionado, remova), o que significa que temos que atualizar todos os arquivos duplicados
• Ainda precisamos ser capazes de alterar as chaves enquanto o aplicativo está em execução

Nossos pensamentos atuais sobre como podemos abordar isso são:

• Mova a configuração para o código compilado dinamicamente (possivelmente Boo, Binsor ou JavaScript)
• Tenha alguma forma de configuração de diferença/mesclagem: combine uma configuração padrão com uma configuração Live/Test/Training e uma configuração específica do site

Answer 1

Qualquer que seja o caminho, acho que pode ser valioso ter a noção de uma única "fonte de verdade" para sua configuração.

A duplicação é boa, se você precisar fornecer configuração a alguns componentes em seu próprio formulário especializado.

Mas, para manter sua sanidade, acho que você deve tentar ter um lugar em que defina toda a configuração referente ao seu aplicativo e, em seguida, um mecanismo bem definido para traduzir isso em entradas dentro da web.config e qualquer outro mecanismo de configuração que você tem que apoiar.

Dependendo do nível de habilidade de seus parceiros de apoio (se eles quebrarão ou não o XML), imagino que você também queira fornecer um utilitário da GUI para deixá -los girar todos os botões nesta "fonte da verdade" arquivo de configuração, com " Aplique "Código de transformação/atualização de Going and Running para fazer as alterações necessárias no web.config & Friends.

Em seguida, para gerenciar sua configuração para diferentes sites/clientes, teoricamente você tem um arquivo de configuração para gerenciar.

Observação: No ASP.NET 4.0, um mecanismo de transformação de configuração no tempo de construção estará disponível (ver http://blog.hmobius.com/post/2010/02/17/aspnet-40-part-4-config-transformation-files.aspx), o que pode facilitar essa tarefa. Parece que você pode usar isso com alguns hacks para projetos sem web (veja http://philbolduc.blogspot.com/2010/03/using-config-transforms-toide-web.html).

No entanto, se você precisar fazer essas alterações no tempo de implantação, poderá estar preso ao escrever ferramentas personalizadas para fazer isso, embora pareça que as transformações XDT podem ser o caminho a seguir, já que você deseja adicionar/ atualizar/remover itens.

Answer 2

Se o código usando os itens de configuração referidos for o código que você gerencia/pode alterar (e tudo em execução no código de código gerenciado/c#), eu procuraria portar as chamadas de método que colocam as configurações para uma chamada para uma aula de singleton com pelo menos um getString () Método nele.

GetObject () pode ser muito útil (confira o material de serialização .NET XML - os americanos soletram com um 'z': serialização) ... útil para muitas coisas, mas também porque significa que você pode começar entradas únicas na loja.

Em relação ao uso de uma única loja (uma tabela de banco de dados com acesso em cache) ou use sua nova fachada de configuração apenas para encapsular onde os itens de configuração são armazenados - isso depende de você ... Eu prefiro fortemente uma única loja por implantação de produto para configuração, porque então então Você sempre sabe exatamente onde procurar e onde fazer alterações. Todas as referências de serviço da web (WCF ou não) podem ser constituídas e chamadas usando strings fornecidos pelo tempo de execução ... :)

Em termos de valores de cache para chaves - eu uso o meu próprio em cache de memória (para aplicativos menores) porque a sobrecarga na pilha é gerenciável ... coisas como o memcache podem funcionar aqui (o Config Store é acessado pelo TCP/na rede em algum lugar) ...

Edite algo como:

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

Você pode considerar os scripts NANT para automação combinados com algum utilitário .NET personalizado para manipular as teclas de configuração.