"Se queremos que tudo fique como está, é preciso mudar tudo" - Giuseppe Tomasi
Um dos meus dilemas quando comecei a desenvolver sistemas era quando eu deveria utilizar o banco de dados para criar uma lista de opções ou quando deveria implementá-lo "na própria mão", usando constantes.
Passado algum tempo, descobri que sempre é interessante utilizar o banco de dados quando você quer permitir ao usuário criar, editar e excluir suas próprias configurações ou quando as constantes que você está pensando em criar não são lá muito constantes.
Tome, por exemplo, um cadastro em que deve ser informado o sexo de um usuário. Neste caso, há somente duas opções: masculino e feminino, então qual a necessidade de criar uma tabela no banco de dados para guardar somente essas duas informações que sabemos que não irá mudar? Nenhuma, só tornaria suas consultas ao banco mais lentas.
Lista com os meses do ano? Tampouco haveria necessidade, ainda mais que há uma relação direta entre o inteiro(1-12) e o nome do mês(jan-dez)
Lista com as séries escolares? Neste caso, eu já consideraria criar uma tabela no banco de dados, posto que são "constantes" sujeitas a mudanças por conta de novas regulamentações governamentais.
Sanada essa dúvida fiquei feliz por algum tempo. Aí, de repente, surgiu uma outra: quando eu deveria utilizar arquivos de configuração em minha aplicação?
Neste ponto, eu comecei a observar o que mais motivava a utilização de arquivos de configuração : conferir mais poder e facilitar a vida do desenvolvedor. Quando você cria arquivos de configuração você está geralmente pensando no desenvolvedor; quando você cria configurações em forma de tabelas no banco, está pensando em customizações para o usuário final.
Pense, por um instante, em algumas aplicações que utilizam arquivos com dados de configuração. Pra citar duas em JavaScript: NPM e o Ghost, o gerenciador de conteúdo deste blog. O primeiro faz uso do arquivo package.json pra manipular os módulos necessários ao Node e o segundo separa em um arquivo chamado config.js as configurações do banco de dados, de email e do ambiente da aplicação(teste,desenvolvimento e produção). Outros exemplos? Sim, os diversos arquivos de configuração dos pacotes instalados no sublime responsáveis por alterar os comandos, conforme a preferência do desenvolvedor. O próprio AutoCAD também permite ao usuário alterar os comandos, sendo um exemplo de arquivo de configuração destinado ao usuário final.
A lista de exemplos e de utilidades para dados de configuração é enorme, mas mais importante é saber por que usar dados de configurações, quando e ilustrar o processo com um exemplo.
Por Que Separar Dados de Configuração?
O motivo principal é não gerar risco desnecessário ao editar o código fonte. Isso dá confiança a você ou a outros desenvolvedores para realizar alterações. Em outras linguagens, isso significa também que você não precisa compilar novamente toda a aplicação para alterá-la em produção.
O Que São e Exemplo
Dados de configuração são "hardcoded values" em uma aplicação que possivelmente irão mudar. Isso significa valores brutos, inseridos à mão, que terão efeitos diretos na aplicação, provavelmente irão se repetir e tem chance de serem alterados. Veja o exemplo abaixo do livro Maintainable JavaScript, você é capaz de identificar 3 candidatos a dados de configuração?
// Dados de configuração embutidos no código.
function validate(value) {
if (!value) {
alert("Invalid value");
location.href = "/errors/invalid.php";
}
}
function toggleSelected(element) {
if (hasClass(element, "selected")) {
removeClass(element, "selected");
} else {
addClass(element, "selected");
}
}
O primeiro dado de configuração é a string "Invalid value" que, sendo uma mensagem mostrada na interface de usuário, provavelmente irá mudar. O segundo é "/errors/invalid.php", posto que URLs tendem a mudar, conforme o processo de desenvolvimento e decisões arquiteturais. O terceiro é o nome da classe CSS "selected". Ela se repete três vezes no código, significando um trabalho triplo para substituí-la por outra classe e com maior risco de eventualmente deixar passar alguma atribuição.
Quando e Como
Como falamos, dados de configuração são valores brutos que possivelmente irão mudar dentro da aplicação. Alguns exemplos de quando usá-los são:
- URLs;
- Strings na Interface de Usuário(UI);
- Valores únicos e que se repetem ao longo da aplicação;
- Configurações/Definições (itens por página, máximo de palavras por tweet, etc.);
- Qualquer valor bruto que possa eventualmente mudar;
Assim, no exemplo anterior, o primeiro passo para separar os dados de configuração seguiria a seguinte implementação:
// Dados de configurações
var config = {
MSG_INVALID_VALUE: "Invalid value",
URL_INVALID: "/errors/invalid.php",
CSS_SELECTED: "selected"
};
function validate(value) {
if (!value) {
alert(config.MSG_INVALID_VALUE);
location.href = config.URL_INVALID;
}
}
function toggleSelected(element) {
if (hasClass(element, config.CSS_SELECTED)) {
removeClass(element, config.CSS_SELECTED);
} else {
addClass(element, config.CSS_SELECTED);
}
}
Em seguida, para externalizar completamente os dados de configuração, poderia ser usado um arquivo no formato JSON que possui a vantagem de ter compatibilidade com várias linguagens:
{"MSG_INVALID_VALUE":"Invalid value","URL_INVALID":"/errors/invalid.php",
"CSS_SELECTED":"selected"}
Você pode encontrar um exemplo de como você armazenaria dados de configuração, usando Node aqui(https://docs.nodejitsu.com/articles/file-system/how-to-store-local-config-data)
Conclusão
A prática de separar os dados de configuração permite alterações que não comprometem a lógica da aplicação, além de permitir customizações normalmente voltadas a outros desenvolvedores. Em aplicações de maior escala, esse com certeza é um grande benefício, enquanto em menores, vale a pena considerar a prática à medida que o sistema for tomando maiores proporções.
