A lógica de negócios não entra no banco de dados
Se estamos falando de aplicativos multicamadas, parece bastante claro que a lógica de negócios, o tipo de inteligência que executa uma determinada empresa, pertence à camada de lógica de negócios, e não à camada de acesso a dados.
Bancos de dados fazem algumas coisas muito bem:
- Eles armazenam e recuperam dados
- Eles estabelecem e reforçam relacionamentos entre diferentes entidades de dados
- Eles fornecem os meios para consultar os dados em busca de respostas
- Eles fornecem otimizações de desempenho.
- Eles fornecem controle de acesso
Agora, é claro, você pode codificar todos os tipos de coisas em um banco de dados que dizem respeito às suas preocupações comerciais, como taxas de imposto, descontos, códigos de operação, categorias e assim por diante. Mas a ação comercial que é feita com base nos dados geralmente não é codificada no banco de dados, por todos os tipos de motivos já mencionados por outros, embora uma ação possa ser escolhida no banco de dados e executado em outro lugar.
E, claro, pode haver coisas que são realizadas em um banco de dados por desempenho e por outros motivos:
- Fechando um período contábil
- Processamento de números
- Processos em lote noturnos
- Failover
Naturalmente, nada está gravado em pedra. Procedimentos armazenados são adequados para uma grande variedade de tarefas, simplesmente porque eles vivem no servidor de banco de dados e possuem certas vantagens e vantagens.
Procedimentos armazenados em todos os lugares
Há um certo fascínio em codificar todas as suas tarefas de armazenamento, gerenciamento e recuperação de dados em procedimentos armazenados e simplesmente consumir os serviços de dados resultantes. Você certamente se beneficiaria do máximo possível de otimizações de desempenho e segurança que o servidor de banco de dados poderia fornecer, e isso não é pouca coisa.
Mas o que você arrisca?
- Bloqueio do fornecedor
- A necessidade de desenvolvedores com conjuntos de habilidades especiais
- Ferramentas de programação espartana, em geral
- Acoplamento de software extremamente preciso
- Nenhuma separação de interesses
E, claro, se você precisar de um serviço da Web (que provavelmente é o lugar para onde isso está indo, de qualquer forma), você ainda terá que criar isso.
Então, qual é a prática típica?
Eu diria que uma abordagem típica e moderna é usar um Object-Relational Mapper (como o Entity Framework) para criar classes que modelam suas tabelas. Você pode então falar com seu banco de dados através de um repositório que retorna coleções de objetos, uma situação que é muito familiar para qualquer desenvolvedor de software competente. O ORM gera dinamicamente o SQL correspondente ao seu modelo de dados e as informações solicitadas, que o servidor de banco de dados processa para retornar os resultados da consulta.
Quão bem isso funciona? Muito bem e muito mais rapidamente do que escrever procedimentos armazenados e visualizações. Isso geralmente cobre cerca de 80% dos requisitos de acesso a dados, principalmente o CRUD. O que cobre os outros 20%? Você adivinhou: procedimentos armazenados, que todos os principais ORMs suportam diretamente.
Você pode escrever um gerador de código que faz a mesma coisa que um ORM, mas com procedimentos armazenados? Certamente você pode. Mas os ORMs são geralmente independentes do fornecedor, bem compreendidos por todos e melhor suportados.