Revista MSDN Magazine Edição 04 - À Procura do Santo Graal

Clique aqui para ler todos os artigos desta edição

À Procura do Santo Graal

por Mauro Sant’Anna

Sem dúvida, a OOP (Programação Orientada a Objetos) apresentou bons resultados em bibliotecas de classe como MFC e na própria .NET Framework. No entanto, usar OOP para programas “comuns” é um pouco mais complicado. Quando falo em programas “comuns”, refiro-me a aplicativos que acessam bancos de dados, como contabilidade, folha de pagamentos e faturamento. Ou seja, a maioria dos aplicativos que você e eu estamos desenvolvendo.

Devo confessar que procuro há anos por uma boa metodologia e/ou biblioteca que permita usar a OOP com bancos de dados. Para mim, essa solução se assemelha ao Graal, o cálice santo supostamente usado por Jesus Cristo na última ceia e perseguido por personagens medievais, como o mítico Artur e seus cavaleiros da távola redonda, de Camelot. Essa metodologia, na minha opinião, deve ter as seguintes características:

1.Permitir o uso de técnicas comprovadas de análise de bancos de dados (normalização, modelos EER etc); você pode me chamar de dinossauro, mas criar o banco de dados antes de partir para o desenvolvimento ainda me parece uma boa idéia, visto que tanta coisa depende do banco;

2.Ser relativamente fácil de aprender e implementar;

3.Não exigir que os programadores sejam gênios;

4.Ser implementável em linguagens “comuns” – nada de Smalltalk, Eiffel ou outras coisas bizarras;

5.Usar bancos de dados “comuns”, como SQL Server, Oracle e DB/2;

6.Ter boa performance;

7.Oferecer boa produtividade no desenvolvimento;

8.Ser esteticamente “correta”: devemos olhar para trás e gostar do caminho que trilhamos.

Depois de tantos anos procurando o Graal, estou aqui a confessar publicamente uma heresia: acho que ele não existe. Cheguei ao ponto onde “a ausência da prova revelou-se a prova da ausência”.

Mas, peraí, não existem bibliotecas OOP para acesso a bancos de dados relacionais? Sim, bem, talvez, veja bem, até existem. O problema é que o mapeamento “OOP-relacional” é algo extremamente difícil de ser feito – isso para ser bonzinho. Geralmente, essas bibliotecas não satisfazem a nenhum dos critérios acima (o que dirá a todos).

O problema é que temos dois modelos bem diferentes: de um lado o SQL orientado a conjuntos que, por sua vez, têm alguma relação com tabelas em bancos de dados. Do outro lado, temos objetos em memória. Para obtermos resultados, precisamos conciliar esses dois mundos, o que tem-se revelado uma tarefa bastante elusiva. Veja algumas das questões:

ØUma das principais vantagens da OOP é a herança, mas os bancos de dados relacionais como SQL Server e Oracle não suportam herança;

ØUma classe contém dados e comportamentos; o banco de dados contém, em princípio, apenas dados;

ØOs “comportamentos” no banco de dados podem ser implementados como “Stored Procedures”, mas estas não têm nada a ver com os métodos das classes OOP; as bibliotecas de mapeamento “OOP-Relacional” em geral ignoram a existência das stored procedures;

ØOs dados na OOP permanecem na memória efêmera; os dados nos bancos de dados permanecem no disco e sobrevivem ao desligamento do servidor;

ØOs dados no banco de dados são “late bound” e têm seus nomes resolvidos sempre em tempo de execução; os dados nas classes são normalmente “early bound” e têm seus nomes resolvidos (e às vezes até mesmo descartados) em tempo de compilação.

Além dos problemas “filosóficos” citados acima, existem também problemas práticos, normalmente relacionados à performance. Por exemplo: é difícil traduzir do modelo OOP para o banco de dados comandos em lotes (do tipo “update tabela where condicao”) de forma eficiente. No que se refere à segurança: atualmente, uma corrente muito em voga nas grandes empresas defende que a atualização dos bancos só deve ser feita através de stored procedures (jamais com comandos SQL vindos dos clientes). Como conciliar esse desejo com as bibliotecas de mapeamento OOP-Relacional, que quase sempre dependem da geração de comandos SQL em tempo de execução para funcionar?

Por todas essas razões, perdi a esperança de encontrar o tal do elusivo Graal do “casamento OOP-Relacional”.