Programando de forma simplificado com JDBC – Parte 2

 

Simplificando a vida do desenvolvedor

Muitos desenvolvedores com os quais trabalhei não são modeladores de objetos ou modeladores de banco de dados; representam uma terceira categoria de programadores. Eles se sentem igualmente confortáveis com objetos e com o SQL; são os desenvolvedores em PowerBuilder. O PowerBuilder tem suas qualidades boas e ruins, como qualquer produto, mas em minha opinião, tem uma jóia: a janela de dados. Em vez de mapear toda a tabela ou resultset potencial em uma classe diferente, o PowerBuilder tem uma única classe: a janela de dados. Simplesmente falando, a janela de dados equivale a um ResultSet atualizável. Para usá-la, simplesmente emita uma consulta, qualquer consulta, não importa o quão complexa seja. Qualquer resultado retornado poderá ser formatado facilmente, poderá ser ordenado e poderá ser navegado em qualquer ordem. Ainda mais, quaisquer dos dados devolvidos poderão ser modificados e ser submetidos ao banco de dados mediante uma chamada de método. A janela de dados também controla o gerenciamento de todas as chaves primárias e transações.

 

Simplificando a vida do desenvolvedor, versão 1

Estando já convencido de que a janela de dados pode ser uma solução efetiva, comecei a escrever algo semelhante em JDBC com Java. Obtive uma solução bastante completa, mas havia problemas. Um das vantagens da janela de dados é que ela administra automaticamente chaves primárias e tipos de dados de colunas. Isto reduz significativamente o trabalho do desenvolvedor. O problema com minha implementação era a disponibilidade de drivers de banco de dados de alta qualidade. A implementação depende pesadamente de resultsets de metadados. Estes metadados, como quaisquer outros, tais como Java Reflection e XML Schema, serão poderosos quando for preciso. O problema é que muitos drivers, até mesmo aqueles de alta qualidade, não retornam todos os metadados necessários. Nada na especificação do JDBC exige isto dos drivers. Os métodos existem, mas não trabalham necessariamente para todas as combinações de drivers de bancos de dados.

Pelo que eu sei, o PowerBuilder também tem problemas de metadados ao utilizar o ODBC e os drivers nativos. A solução é implementar drivers de banco de dados personalizados para cada banco de dados suportado para garantir funcionalidade robusta. Tolamente, desperdicei muito tempo investigando por que alguns drivers não proviam todos os metadados. A resposta é simples: há muitos bancos de dados, muitos drivers e algumas pessoas que os desenvolvem. Provavelmente, metadados perfeitos não estão no topo da lista de prioridades; não é provável que seja atingido cem por cento de suporte no futuro próximo.

 

Simplificando a vida do desenvolvedor, versão 2

Tentei descobrir as necessidades de metadados na esperança de suportar os drivers de banco de dados e bancos de dados mais populares. Isto provou ser melhor, mas menos conveniente que a implementação original, e alguma coisa poderia ainda ser omitida.

Concluí que talvez estivesse sendo muito preciosista. Como outros, tentei resolver o problema de forma ampla. Reduzi meu escopo para algo mais manipulável, algo simples. Decidi dar prioridade às facilidades de navegação, formatação, análise gramatical e validação. Abandonei a idéia de gerenciar chaves primárias e deixei isto para o desenvolvedor. Concluí que no fim as chaves primárias não são a parte mais difícil do gerenciamento.

O resultado final é uma solução escalável que tolera limitações de drivers de banco de dados disponíveis, mas ainda é relativamente fácil de usar.