Vivemos um novo momento no desenvolvimento de software onde a abstração do relacionamento da aplicação com o banco de dados tende a ser cada vez maior, hoje o banco de dados não é mais o centro da aplicação.

Este é um assunto muito polêmico e que interessa tanto aos desenvolvedores de software como aos especialistas em banco de dados (DBA’s e etc).

Quem desenvolve software a mais de 5 anos pôde acompanhar uma nova tendência crescendo rapidamente, que é a forma na qual a aplicação se relaciona com o banco de dados. Infelizmente ainda hoje os profissionais aprendem na faculdade ou no ambiente de trabalho um modelo de desenvolvimento que já está no passado, e é esta minha motivação em escrever este artigo.

Há muitos anos nosso processo de desenvolvimento vem ocorrendo de uma maneira clássica (e hoje em dia inadequada), o DBA desenvolve toda a modelagem do banco de dados elencando as entidades (tabelas) e seus relacionamentos conforme a necessidade e seu próprio entendimento do negócio, após isso aplicam-se as regras de normalização, valida-se o MER (modelo-entidade-relacional) e pronto! Basta escrever as Stored Procedures, Triggers e Views com as regras de negócio e entregar para o desenvolvedor desenvolver a aplicação que vai consumir o banco.

Então a aplicação é uma camada “casca” que envolve o banco de dados, consumindo e inserindo novas informações?

Isso parece meio ridículo para um desenvolvedor de software hoje em dia, mas esse modelo “3 camadas” já foi muito (e ainda é) pregado e defendido por ai. A primeira camada é a UI (user interface) a segunda é o “core” da aplicação que consome diretamente o banco de dados e a terceira é o próprio banco.

Um dos pontos muito defendidos nessa distribuição de 3 camadas era que a máquina do usuário não precisava possuir muito recurso computacional e nem conhecer as regras de negócio uma vez que poderia haver uma engenharia reversa da aplicação instalada.
Esse argumento não é mais válido hoje em dia dado a infinidade de recursos computacionais e tecnológicos que possuímos (Web, SOA, etc.).

Um outro forte argumento para a centralização no banco de dados é de que o servidor de banco de dados é uma máquina muito rica em recursos computacionais e consegue processar as regras de negócio com mais velocidade do que um servidor de aplicação.
Esse argumento além de passado ocasiona diversos problemas que serão abordados a seguir.

Regras de negócio em Stored Procedures é uma má prática

Poderia elencar diversos adjetivos para a utilização de regras de negócios em stored procedures, porém vamos considerar apenas uma má prática que deve ser evitada a todo custo. Listarei alguns problemas/dificuldades muito frequentes com a adoção desta prática:

• A linguagem TSQL (Transact SQL) é muito limitada em comparação as linguagens atuais, requer mais código e dificulta a interpretação/entendimento, requer mais esforço aumentando o tempo de codificação.
• É muito difícil escrever testes de unidade para regras de negócio em stored procedures.
• O mecanismo que gera o plano de execução para as stored procedures não trabalha bem com condições (IF, Case, etc) podendo ocasionar uma lentidão muito grande ao chamar uma stored procedure com diversos fluxos.
• Quebra o conceito de responsabilidade única, a regra pode estar parte no banco, parte na stored procedure. Além de aumentar o esforço na analise e detecção de problemas.
• Estimula a escrita de milhares de linhas de código em apenas uma store procedure, algumas delas com mais de 4.000 linhas são bem fáceis de se encontrar por ai. O esforço de manutenção é centenas de vezes maior, além do risco de introdução de novos bugs.

Existem diversos contras além dos listados, porém estes citados são base de muitos problemas comuns no dia a dia. Não entenda que as stored procedures não devem ser utilizadas, até devem dependendo do cenário, porém sem regras de negócio.

E sobre o uso das Triggers?

Dentre um determinado conjunto de decisões que podem ocasionar sérios problemas entre aplicação e banco de dados, uma delas é o uso de Triggers.

Triggers podem ser úteis em alguns cenários, porém existem outras opções mais eficazes. Não há nada que uma trigger faça que não possa ser substituído por outro recurso (externo do controle do banco de dados) e que funcione de forma mais controlada, elegante, e lógico, testável.

O servidor de banco de dados é muito mais rápido que o servidor de aplicação

Fato! E deve ser mesmo, pois a questão é, quantos bancos de dados é possível escalar lado a lado? Manter bancos de dados sincronizados não é uma tarefa simples e não custa nada barato. Na maioria das aplicações existe um único banco de dados ativo (outros de contingência) e N servidores de aplicação consumindo o mesmo banco. É muito mais fácil escalar o servidor de aplicação e muito mais barato (basta conferir os valores de licenciamento de um SGBD). A própria aplicação de atualizações nos servidores de aplicação é muito mais simples do que no servidor de banco de dados.

Não é por que o banco de dados tem capacidade computacional superior que ele deve ser responsável pelo negócio em si, o banco de dados é um repositório de dados, ele deve ter alta disponibilidade para entregar com a maior velocidade possível as consultas. Utilizar os recursos computacionais do banco de dados para validar o negócio é queimar dinheiro e ocasionar problemas de performance.

O mundo é muito maior que o relacionamento entre tabelas no banco de dados

Podemos dizer que hoje o modelo de programação orientada a objetos dominou o mercado de software, sim existem ainda outros modelos (procedural, funcional, etc) porém a grande parte do mercado aderiu a famosa OOP.

Programar orientado a objetos é uma forma muito mais rica de mapear o mundo real do que as simples formas de relacionamento presentes de banco de dados relacionais, existem bancos de dados NoSQL, orientados a objetos, baseados em grafos e etc, porém não são populares como os relacionais (MSSQL, Oracle, MySQL, etc).

Se a orientação a objetos é uma forma de mapeamento mais rica que o modelo entidade-relacionamento dos bancos de dados, deveríamos então modelar nossa aplicação baseadas em classes e não em tabelas? Exato!

Partindo desta decisão como ficaria o relacionamento de uma aplicação orientada a objetos consumindo um banco de dados relacional?
Alguém já resolveu esse problema faz muitos anos, são os famosos ORM’s

O ORM (Object-relational mapping) faz justamente este trabalho, mapeando entidades de software (classes) para entidades de bancos de dados (tabelas). Com isto é possível que uma única tabela de banco de dados seja representada por N classes e vice-versa.

Os ORM’s abstraem o banco de dados

Abstrair o banco de dados significa parar de se preocupar com a modelagem do banco na hora de modelar o sistema, a modelagem pode ser feita em UML utilizando diagramas de classes entre outros diversos tipos de diagramas, no final o mapeamento das suas entidades de software estarão muito melhores definidas do que se tivessem sido feitas com base no MER de banco de dados relacionais.

O ORM cuida para que o seu mapeamento orientado a objetos faça sentido com o mapeamento entidade relacionamento.

A abstração não para por ai, através dos ORM’s é possível desligar a dependência tecnológica do banco de dados na aplicação, a aplicação não estará mais acoplada a uma tecnologia de banco de dados, trocar um banco de dados de uma aplicação não é nada trivial, porém se abstrairmos/desacoplarmos a aplicação do banco através do uso de um ORM essa tarefa seria infinitamente mais fácil.

Produtividade! Desenvolvedores não precisam codificar todas as consultas em linguagem TSQL, o ORM promove um novo modelo de consumo do banco de dados, o ORM fica encarregado de gerar as queries para comunicar-se com o banco, quando necessário o desenvolvedor pode fornecer uma query específica para ser utilizada no banco através do ORM.

Escreva sua aplicação e ganhe banco de dados

O modelo Code First já está presente faz alguns anos no mercado e seu uso vem crescendo de forma gigantesca, uma vez que possuímos o ORM para abstrair o banco de dados, por que não deixar com ele também a criação e atualização do banco?

Isso mesmo, basta mapear todo seu universo do negócio em classes, escrevê-las e no final gerar o banco de dados que se adeque a modelagem da aplicação. Afinal o banco de dados é um repositório de dados.

O Entity Framework em sua nova versão (7) trabalhará apenas com o modelo Code First, para desenvolvimento de aplicações com base de dados já existentes será possível utilizar os recursos de engenharia reversa. A atualização do banco pode ser feita também através de recursos como Migrations.

E o DBA? Morreu?

Muito pelo contrário! Quem vai garantir o perfeito funcionamento do banco? Backup, segurança, implementações de recursos de performance, acompanhar problemas em tempo real e prover rápidas soluções, dividir tabelas especiais em discos independentes e etc… Isso tudo é trabalho do DBA.

Uma coisa que está errada faz muito tempo é que a modelagem de banco de dados é de responsabilidade do DBA, criar mais um campo na tabela, escrever uma stored procedure e outras atividades desse tipo eram de decisão do DBA. Quantas vezes um desenvolvedor já precisou explicar para o DBA o por que precisava de um campo a mais numa tabela, ou por que uma stored procedure devia ser alterada. Isso não faz sentido.

Em um time de desenvolvimento o número de DBA’s é muito menor do que o número de desenvolvedores, nesse cenário o DBA iria trabalhar apenas para atender as necessidades dos desenvolvedores, deixar estas responsabilidades com o DBA é impedir de que ele faça seu real trabalho que é manter o banco de dados altamente disponível utilizando todo seu potencial.

Alguns DBA’s são contra o uso de ORM’s por que ferem seu sentimento de responsabilidade por algo que não deveria ser de sua responsabilidade. Os ORM’s aos poucos estão dando de volta aos desenvolvedores o que era para ser seu desde sempre, o domínio da modelagem e desenvolvimento da aplicação. E claro, numa situação de dúvida não custa nada perguntar a opinião do DBA.

Não importa onde estão os dados

Hoje os bancos de dados relacionais não são a única fonte de dados, os dados podem estar disponíveis através do consumo de serviços (SOA, WCF, WebAPI), podem estar em bancos NoSQL (MongoDB, Redis, etc), podem estar em bancos de dados In-Memory (Hekaton, MemSQL) ou simplesmente sendo abstraídos pelo seu ORM.

Por exemplo no DDD (Domain-Driven-Design) temos uma abstração tão grande que realmente não importa de onde vem os dados, a aplicação não fica dependente disto (apenas na camada de configuração de dados). É neste sentido que devemos caminhar, escrever aplicações focadas no domínio do negócio, que por si próprias saibam resolver qualquer problema e que possam ser expostas através de serviços para que sejam consumidas através de qualquer plataforma, device e etc…

Hoje todo gestor de desenvolvimento fala e se interessa por métodos ágeis, não existe agilidade sem teste, testes de unidade e testes de integração, abstrair o banco de dados é uma forma de promover a possibilidade dos testes, da análise do código escrito, da validação da regra de negócio, poder realizar um Mock de um repositório sem bater no banco de dados e etc. Num mundo onde dependemos de um banco de dados presente para realizar um teste de unidade, com certeza esse não é um mundo muito ágil.

Os banco de dados relacionais irão tornar-se obsoletos no futuro?

Essa mesma pergunta foi feita quando surgiram os bancos de dados orientados a objetos, bancos de dados de grafos, NoSQL.

Os bancos de dados relacionais estão acompanhando a evolução tecnológica, tornando-se cada vez mais performáticos, com mais recursos para alta disponibilidade e etc, porém de outro lado estão surgindo conceitos como Big Data que impulsiona a utilização de bancos NoSQL, redes sociais que utilizam muito o conceito de banco de dados de grafos, entre diversas novidades que não param de surgir.

Acredito que cada modelo de aplicação possui um tipo (ou tipos) de banco de dados que melhor atendem o cenário. O importante é saber como e quando utilizar cada um deles.

Para finalizar

O mundo muda constantemente e cada vez mais rápido, conceitos aprendidos na faculdade anos atrás ou até mesmo hoje em dia podem estar em constante desuso. Políticas antigas de empresas ou até mesmo profissionais conservadores de padrões ultrapassados são muito comuns no nosso mercado.

É importante estar antenado e preparado para quebrar paradigmas, pesquisar e aprofundar-se em melhores práticas de desenvolvimento de software, sempre prezando reusabilidade, performance, escalabilidade e com certeza qualidade garantida por testes de unidade.

Além deste artigo eu participei de um bate papo muito construtivo sobre este assunto com meus colegas do AspNetCast, assista o vídeo também.

* Assine meu canal no Youtube

Vamos continuar a troca de conhecimentos, deixe seu comentário abaixo, pode ser dúvida, elogio ou sua opinião que é sempre muito importante 😉