Quando usar constantes x arquivos de configuração para manter a configuração

Frequentemente, luto comigo mesmo sobre a possibilidade de colocar determinadas chaves no meu web.config ou em uma classe Constants.cs ou algo assim.

Por exemplo, se eu quisesse armazenar chaves específicas do aplicativo para qualquer que fosse o caso ... Eu poderia armazená-lo e obtê-lo da minha configuração da web por meio de chaves personalizadas ou consumi-lo referenciando uma constante na minha classe de constantes.

Quando você deseja usar constantes sobre chaves de configuração?

Esta questão realmente se aplica a qualquer idioma que eu penso.

Pessoalmente, eu usaria apenas constantes como valores padrão e deixei que elas fossem substituídas por valores de um arquivo de configuração.

Se o aplicativo receber argumentos de linha de comando, eles substituiriam os parâmetros do arquivo de configuração.

O valor no arquivo de configuração é mais difícil de manter do que o valor na classe constantes, porque o compilador não verifica se ele existe e é do tipo correto, o IDE geralmente não fornece assistência de código para ele e também porque é mais uma sintaxe para a qual você precisa mudar. durante a programação.

Então, eu sugiro colocar:

• Valores que serão iguais em todas as instalações e constantes no código. Existem algumas vantagens em colocá-los em uma classe de constantes (você pode facilmente experimentar vários valores para ver como eles funcionam) e colocá-los no módulo que os utiliza (não é necessário abrir mais um arquivo ao modificar esse módulo e evitando um arquivo que todos editariam causando conflitos no controle de versão).
• Valores que (podem) precisam ser alterados por instalação no arquivo de configuração. E você provavelmente deseja colocar o padrão no código de qualquer maneira, portanto, se o valor não estiver definido na configuração, o aplicativo ainda (de alguma forma) funcionará.

A mudança de constantes exige a reconstrução do aplicativo na maioria dos casos. Em outras palavras, constantes permanecem constantes quando alguém não tem acesso ao código.

Portanto, qualquer informação que o usuário final precise fornecer (e precise alterar) deve entrar nos arquivos de configuração. A maioria dos outros precisa ficar sob constantes. No entanto, deve haver padrões legítimos ou tratamento de exceção de erro se os arquivos de configuração estiverem quebrados.

Elementos que não fazem parte da abstração do objeto (ou seja, se as constantes que não devem ser modificadas por objetos externos (de chamada) provavelmente estão ocultas e significam essencialmente que seriam melhores como constantes privadas do que arquivos de configuração.

Quando existem muitos elementos de configuração que pertencem a objetos diferentes, não relacionados entre si, e quando tantos objetos precisam extrair arquivos de configuração (iguais ou próprios), é provável que essas coisas devam ser constantes.

Uma regra simples é criar constantes quando você sabe que trabalhará com um conjunto fixo de valores que sabe que podem ser aplicados a qualquer contexto, sem precisar alterar; fornecer configurações externas para todo o resto.

Um bom exemplo de constantes seria se todas as formas com as quais você trabalhou pudessem ser SQUAREou ROUND. Na maioria dos idiomas, você poderá aproveitar o fato de que esse valor não muda com o tempo, alocando-o apenas uma vez e otimizando o acesso.

As configurações externas são necessárias quando você precisa recuperar o valor dinamicamente porque não pode assumir antecipadamente o valor com o qual trabalhará, mas isso não significa que você precise fazer uma troca de desempenho: para os valores de configuração que você espera que sejam Atualmente, quando feito corretamente, você paga apenas o preço de recuperá-los uma vez e ainda recebe todos os benefícios.

Você também pode simplesmente usar este padrão de design: "convenção sobre configuração".

http://msdn.microsoft.com/en-us/magazine/dd419655.aspx http://en.wikipedia.org/wiki/Convention_over_configuration

Uma constante por definição é um local de memória para um valor que não deve ser alterado (como PI).

Presumo que você quis dizer 'parâmetro' e não uma constante

Além do que foi dito, observe que a exposição de variáveis ​​à entrada do usuário a partir do arquivo de configuração pode prejudicar o aplicativo.

Quando possível, não exponha valores no arquivo de configuração sem validá-los no código para ter uma verificação de integridade. Além disso, sugiro que você não coloque parâmetros de regras de negócios (como salário máximo etc.) nos arquivos de configuração e também não use constantes para eles. Esses valores devem ser armazenados no banco de dados com as definições de tabela apropriadas, para que seja aplicada alguma segurança quando forem alteradas e você poderá criar automaticamente versões dos valores dos dados (usando procs armazenados ou logs de banco de dados). Obviamente, isso depende da sensibilidade da sua aplicação.

Se você alguma vez usar arquivos de configuração para armazenar dados, certifique-se de fazer a versão deles.