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”.
