Quase todo sistema acaba persistindo dados de alguma forma, geralmente em grandes repositórios conhecidos como bancos de dados. Recentemente, os Sistemas gerenciadores de Bancos de Dados vêm perdendo sua posição como centro do universo para aplicações coorporativas e vem a pergunta: qual o papel do banco de dados num sistema coorporativo moderno? O banco de dados faz parte do seu sistema ou é apenas um recurso acessado por ele, como um filesystem ou servidor de e-mails?
Bancos de dados coorporativos foram o grande xodó das empresas (ainda são em boa parte delas). O raciocínio é simples: o objetivo do sistema é manipular e armazenar dados. Se eu preciso que vários sistemas (processadores de dados) acessem o mesmo dado, é bom que eles estejam em um lugar comum, daí o SGBD.
O SGBD é o repositório de dados supremo, formando o Banco de Dados Coorporativo. Este, que fisicamente pode estar espalhado em diversos SGBDs de fabricantes diversos, é acessado por todos os sistemas. Na verdade, ao especificar um sistema neste ambiente a coisa mais problemática costuma ser sentar-se com a equipe de DBAs responsável para que esta avalie suas necessidades, geralmente criando views que permitem ao seu sistema acessar os dados.
O problema neste caso é que na evolução da tecnologia, não são apenas os dados que são comuns a diversos sistemas, mas também a lógica, o processamento. Não é admissível num sistema moderno a existência de lógica duplicada, um sistema deve reutilizar os componentes (ou serviços) providos por outros.
Ok, mas e os dados? Bem, os componentes de software (sejam business components vindos de CBD ou serviços SOA ou qualquer outra coisa neste sentido) possuem como grande característica o seu encapsulamento. A lógica interna ao componente, suas estruturas de dados e demais aspectos não devem vazar para fora deste. Isto inclui os dados.
Os dados pertencentes a um componente não devem vagar para fora dele. De uma maneira geral, um componente recebe e retorna apenas objetos por valor, ou seja: cópias dos objetos que mantêm dentro dele, que podem ser modificados pelo cliente e não vão interferir os objetos reais. Com a tecnologia atual e dependendo da granularidade do componente isto nem sempre é viável ou desejável, mas é a teoria (para este tipo de decisão que você precisa de um arquiteto experiente).
Então, se nossos componentes têm por princípio básico proteger a implementação de algum conceito, devemos permitir acesso direto á base de dados? Não, pelo menos não enquanto pudermos evitar. O acesso aos dados deve ser feito unicamente pela API do componente, nunca quebrando o encapsulamento deste para injetar dados diretamente no banco. Veja o diagrama acima, bases de dados sequer são mencionadas!
Independente de o seu sistema ser construído com componentes, serviços ou apenas uma grande massa monolítica de código (como são a maioria dos sistemas), é importante definir o que é banco de dados corporativo do que é o repositório que guarda os dados da sua aplicação/componente/serviço.
Se sua aplicação (/componente/serviço) não guarda dados encapsulados, ou seja: se sua empresa insiste que você use um banco de dados coorporativo, trate o SGBD como um outro sistema com o qual você se comunica. Se seu sistema não pode garantir que os dados neste depósito não serão alterados por outros sistemas então o que você tem é uma integração, não um lugar para guardar seus objetos. Neste caso, utilize as técnicas clássicas de Mappers e Anticorruption-Layers.
Se você precisa acessar dados em um SGBD corporativo, utilize também estas técnicas. Não é porque seu sistema se comunica com este outro componente (o banco corporativo) via JDBC que ele é sua persistência. Utilizar um framework de ORM como Hibernate ou EJB 3.0 (JPA) é algo que eu não recomendaria porque o framework vai considerar que o banco de dados é sua persistência, não um outro sistema a ser integrado. EJB 3.0 por exemplo traz o mapeamento entre classes e tabelas para dentro dos seus arquivos-fonte, isto só é desejável se esta informação representa metadados do seu aplicativo, não configuração. Uma abordagem mais sadia mantendo a produtividade de um framework (afinal, ninguém gosta de escrever JDBC…) pode ser obtida utilizando frameworks ORM com propostas diferentes, como o iBatis.
Nestes dois casos, o SGBD é um recurso, não uma parte da aplicação. É como o servidor de e-mail: pode ser crucial para seu sistema funcionar mas não faz parte dele. Mais que esconder a implementação da persistência, a Camada do seu sistema que tem contato com o SGBD deve se preocupar em checar entradas e saídas, pré e pós condições, exatamente como quando fazemos chamadas a outros sistemas ou componentes.
Já no caso oposto, com seu sistema encapsulando completamente o banco de dados, temos o SGBD como o local onde nossos objetos são armazenados. Neste caso o banco de dados faz parte da aplicação e devemos utilizar a Camada de Persistência para acessá-lo. Esta Camada tem por dever esconder da Camada de Negócios detalhes sobre como a persistência é implementada, na verdade ela esconde simplesmente que existe algo chamado Persistência, visto que para a Camada de Negócios persistência é algo transparente.
Apesar de o banco de dados ser fisicamente uma entidade separada do programa (seu binário, WAR, EAR ou o que for), conceitualmente ele faz parte da aplicação. Note que isto não quer dizer que existe um esquema de dados físico (table schema, database ou coisa parecida) para cada componente. O esquema de dados pode residir em qualquer SGBD, mesmo um compartilhado. O que importa é que quem lê e edita aqueles dados é apenas sua aplicação.
Enquanto componentes ou serviços não fazem parte da arquitetura corporativa das empresas vamos conviver com bancos de dados corporativos, é bom que nossos sistemas se preparem para conviver pacificamente com eles.