Ouvindo Opiniões
Regras de negócio na Aplicação, no Banco de Dados ou no Servidor de Aplicação (n-tier)?
Sobre o autor: Atua no mercado de T.I. desde 1998, prestando consultoria para diversas empresas dentro e fora de sua UF natal. Bacharel em Ciência da Computação e Especialista em Criptografia e Segurança em Redes, é certificado em Delphi 2005 e 2006. Já foi instrutor na TDS Tecnologia, por um longo período, ministrando cursos para alunos de diversas empresas mineiras. Atualmente, tem se dedicado quase que integralmente ao desenvolvimento e consultoria em projetos que utilizem C# como linguagem nativa, além de atuar como Analista Sênior em uma das maiores empresas de comércio do Brasil.
Contato: ibirite@gmail.comEm todos os 3 casos, existem prós e contras. Mas ao longo dos anos, pude perceber que qualquer radicalismo nesse assunto acaba proporcionando um resultado longe do ótimo. Portanto, idealizei algumas diretrizes que me indicam o melhor caminho:
1 - Regras no banco de dados:
Algumas regras jamais devem sair do banco de dados, por questões óbvias de performance. Uma procedure em PL/SQL no oracle (por exemplo) tem desempenho infinitamente superior a qualquer regra definida em um servidor de aplicação. Entretanto, o problema é que testar e homologar regras definidas no banco pode dar uma senhora dor de cabeça. Se o banco do seu cliente tem 1,5 Terabytes de tamanho, é pouco provável que ele também tenha uma segunda máquina com a mesma configuração que a original disponível para você testar as novas regras... Para não fazer confusão, a documentação das regras implementadas no banco deve estar sempre atualizada, senão...
2 - Regras no servidor de aplicação:
Procurar centralizar ao máximo todas as regras de negócio no servidor de aplicação é uma ótima pratica. Só é preciso um pouco de coerência, lembrando-se sempre da regra 1, evitando com que o servidor de aplicação literalmente "agache"... A vantagem principal está na facilidade de manutenção e atualização das regras de negócio.
Na época de ouro do Delphi, criar servidores de aplicação com os famigerados RemoteDataModules era um horror... No .net 3.5, você cria seu servidor de aplicação em minutos, e a performance é excepcional (sem contar os recursos de documentação da própria ferramenta).
3 - Regras na aplicação: Procurar sempre evitar ao máximo criar as regras na aplicação (client) é uma ótima prática, mas não usar regras na aplicação é um pecado mortal. Um simples javascript de validação de CPF/CNPJ pode trazer um ganho em performance imenso em uma aplicação web com muitos usuários simultâneos. Mesmo que as validações sejam refeitas no servidor de aplicação, 1 postback a menos para 300 usuários no mesmo segundo faz o servidor respirar aliviado... Se o cliente da sua aplicação não for Web, tudo o que foi dito aqui também é válido.
Com o tempo, cada desenvolvedor vai aprimorando o seu "feeling" para suas implementações.
Por fim, deixo um conselho: tenha cuidado com os modismos em T.I., mas ao mesmo tempo, mantenha a mente sempre aberta para novas tecnologias. Evite o fanatismo e a idolatria por ferramentas. Delphi, Java, Visual Studio... sem um bom desenvolvedor, nenhuma delas serve para nada. Portanto, valorize a sua experiência, o seu potencial.
Saudações a todos!
Leia também outras opiniões:
- Participe:
- Seja um colaborador
- |
- Sugira um assunto
- |
- Seja avisado de novos assuntos










