Compreendendo as opções de configuração .Net

Question

Estou realmente confuso com as várias opções de configuração para configuração .Net de DLLs, sites ASP.net etc. no .Net v2 - especialmente quando se considera o impacto de um arquivo de configuração na interface da interface do usuário/usuário final da cadeia.

Assim, por exemplo, alguns dos aplicativos com os quais trabalho usam configurações que acessamos com:

string blah = AppLib.Properties.Settings.Default.TemplatePath;

Agora, essa opção parece legal porque os membros são digitados com força e não poderei digitar um nome de propriedade que não exista no IDE do Visual Studio 2005.Acabamos com linhas como esta no App.Config de um projeto executável de linha de comando:

<connectionStrings>
    <add name="AppConnectionString" connectionString="XXXX" />
    <add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>

(Se não tivermos a segunda configuração, alguém lançando uma dll de depuração na caixa ativa pode ter construído com a string de conexão de depuração incorporada nela - eek)

Também temos configurações acessadas assim:

string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];

Agora, isso parece legal porque podemos acessar a configuração a partir do código dll, ou do código exe/aspx, e tudo o que precisamos no Web ou App.config é:

<appSettings>
   <add key="TemplatePath_PDF" value="xxx"/>
</appSettings>

No entanto, é claro que o valor pode não estar definido nos arquivos de configuração ou o nome da string pode ter sido digitado incorretamente e, portanto, temos um conjunto diferente de problemas.

Então...se meu entendimento estiver correto, os métodos anteriores fornecem digitação forte, mas compartilhamento ruim de valores entre a dll e outros projetos.Este último oferece melhor compartilhamento, mas digitação mais fraca.

Sinto que devo estar faltando alguma coisa.No momento, não estou nem preocupado com o fato de o aplicativo ser capaz de gravar valores nos arquivos de configuração, criptografia ou algo assim.Além disso, decidi que a melhor maneira de armazenar strings que não sejam de conexão era no banco de dados ...e a próxima coisa que preciso fazer é armazenar números de telefone para enviar mensagens de texto às pessoas em caso de problemas de conexão com o banco de dados, portanto, eles devem ser armazenados fora do banco de dados!

Answer 1

Nij, nossa diferença de pensamento vem de nossas diferentes perspectivas.Estou pensando em desenvolver aplicativos corporativos que usem predominantemente clientes WinForms.Neste caso, a lógica de negócios está contida em um servidor de aplicativos.Cada cliente precisaria saber o número de telefone para discar, mas colocá-lo no App.config de cada cliente representa um problema se esse número de telefone mudar.Nesse caso, parece óbvio armazenar informações de configuração do aplicativo (ou configurações de todo o aplicativo) em um banco de dados e fazer com que cada cliente leia as configurações a partir daí.

A outra maneira, .NET, (faço a distinção porque, na época anterior ao .NET, armazenamos configurações de aplicativos em tabelas de banco de dados) é armazenar as configurações do aplicativo no arquivo app.config e acessá-las por meio da classe Configurações gerada .

Eu discordo.Sua situação parece diferente.Se todos os aplicativos diferentes estiverem no mesmo servidor, você poderá colocar as configurações em um web.config em um nível superior.No entanto, se não estiverem, você também poderá ter um "serviço de configuração" separado com o qual todos os três aplicativos se comunicam para obter suas configurações compartilhadas.Pelo menos nesta solução você não está replicando o código em três lugares, aumentando o potencial de problemas de manutenção ao adicionar configurações.Parece um pouco exagerado.

Minha preferência pessoal é usar configurações de digitação fortes.Na verdade, eu gero minha própria classe de configurações fortemente digitadas com base na minha tabela de configurações no banco de dados.Dessa forma posso ter o melhor dos dois mundos.Intellisense às minhas configurações e configurações armazenadas no banco de dados (nota:é o caso em que não há servidor de aplicativos).

Estou interessado em aprender estratégias de outras pessoas para isso também :)

Answer 2

Se você usar a guia de configurações no VS 2005+, poderá adicionar configurações fortemente digitadas e obter intellisense, como no seu primeiro exemplo.

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

Isso é armazenado fisicamente em App.Config.

Você ainda pode usar o elemento appSettings do arquivo de configuração ou até mesmo lançar suas próprias subclasses ConfigurationElementCollection, ConfigurationElement e ConfigurationSection.

Quanto a onde armazenar suas configurações, banco de dados ou arquivo de configuração, no caso de strings que não sejam de conexão:Depende da arquitetura do seu aplicativo.Se você possui um servidor de aplicativos compartilhado por todos os clientes, use o método mencionado acima, em App.Config no servidor de aplicativos.Caso contrário, talvez seja necessário usar um banco de dados.Colocá-lo no App.Config em cada cliente causará dores de cabeça no versionamento/implantação.

Answer 3

Acho que sua confusão vem do fato de que parece que seu primeiro exemplo é uma biblioteca caseira, que não faz parte do .NET.O exemplo do ConfigurationManager é um exemplo de funcionalidade integrada.

Answer 4

Apoio a resposta de Rob Gray, mas gostaria de acrescentar um pouco mais.Isso pode ser óbvio demais, mas se você estiver usando vários clientes, o app.config deverá armazenar todas as configurações específicas da instalação e o banco de dados deverá armazenar praticamente todo o resto.

Os aplicativos de cliente único (ou servidor) são um pouco diferentes.Aqui é realmente uma escolha mais pessoal.Uma exceção notável seria se a configuração fosse o ID de um registro no banco de dados, caso em que eu sempre armazenaria a configuração em o banco de dados com uma chave estrangeira para garantir que a referência não seja excluída.

Answer 5

Sim - acho que estamos na situação de dor de cabeça que Rob descreve - temos algo em torno de 5 ou 6 sites e aplicativos diferentes em três servidores independentes que precisam acessar o mesmo banco de dados.Do jeito que as coisas estão, cada um tem seu próprio Web ou App.config com as configurações descritas configurando e/ou substituindo as configurações em nossa biblioteca dll principal de acesso ao banco de dados.

Rob - quando você diz servidor de aplicativos, não tenho certeza do que você quer dizer?A coisa mais próxima que posso pensar é que poderíamos pelo menos compartilhar algumas configurações entre sites na mesma máquina, colocando-as em um web.config mais alto na hierarquia de diretórios...mas isso também não é algo que consegui investigar ...tendo considerado mais importante entender qual das rotas fortes ou fracas é 'melhor'.