Olá,
Como dizia meu pai “Gosto e igual pescoço cada um tem um.”. Mas o objetivo da discussão é válido pois endendo que sempre devemos nos questionar sobre o caminho que tomamos e isso na nossa área se
refere a que tecnologia iremos usar para resolver um determinado problema.
Vou fazer algumas considerações sobre o que foi dito até o momento esperando que isso colabore com a discussão:
- Automatizar sem perder o controle
Entendo que para termos produtividade precisamos em certos momentos automatizar algumas atividades relacionados ao objeto da discussão(persistência). Programar tudo via código sem nenhuma
automação com certeza não será produtivo. O Hibernate nos propicia essa automação mas acaba de certa forma fazendo com que não tenhamos mais o controle do que está sendo executado. Por mais que
saibamos tudo sobre as configurações e HQL/Critéria (o que exige uma curva de aprendizado bem longa) nos deparamos constamente com problemas lançados pelo Hibernate e que não fazemos a mínima
idéia de como solucionar. Acabamos por vezes tendo que recorrer a depurar o código do Hibernate afim de descobrir o que está causando o problema(lentidão, exceptions que não informam claramente a
causa do problema, etc). Isso deixa de ser uma tarefa trivial e produtiva a partir do momento que por exemplo estamos numa fábrica de software onde o programador nem tem acesso a fazer esse
tipo de atividade e que com certeza essa atividade extra de debug acaba fazendo com que se leve mais tempo na produção final do sistema. Pra ficar mais claro minha colocação vou citar um exemplo
prático que passei no trabalho. Temos em nosso ERP muitas tabelas com milhões de registros e nos deparamos com problemas no sistema de NFe onde o Hibernate gera alguns SQL’s que realmente eu não
faria se fosse feito manualmente. Esses SQL’s colocados num plano de execução mostram a ineficiência de como foi montado. Gerando por vezes planos com FULL TABLE access para tabelas extremamente
grandes. Por mais que revisamos o modelo e configurações não conseguimos fazer nenhuma melhoria. Isso nos faz crer que realmente perdemos o controle. Talvez fosse ai o caso de escrever Native Query’s
do hibernate mas nesse caso começa o conflito entre performance x portabilidade. Quantas vezes já ouvimos discussões entre o DBA e o fornecedor do sistema com relação a lentidões provocadas
pelo SQL gerado pelo hibernate? Devemos concordar que com certeza o problema não é no banco, pois se não usamos os recursos que ele oferece como podemos exigir performance?
- Portabilidade[size=18] [/size]
Esse tema depende muito do objetivo a que se propõe o sistema desenvolvido. Se o alvo for clientes onde ele tem a opção de selecionar o banco de dados com certeza vamos precisar de
portabilidade. Em alguns momentos temos que sacrificar isso em função da performance, pois dificilmente vamos conseguir melhorias usando apenas o básico comum a todos os bancos.
O Hibernate assim como outros framework’s ORM vão propiciar portabilidade até o momento e que você precise assumir o controle e escrever coisas nativas/específicas para o banco em questão afim
de resolver problemas por exemplo de perfomance.
- Abandonar o que já aprendemos
Na nossa área em que no momento em que estou escrevendo este comentário tem milhares de pessoas criando mais tecnologias novas para que tenhamos que aprender seria um absurdo
jogar fora o conhecimento adquirido considerando que nem sempre o mercado nos dá o tempo suficiente para absorver novas tecnologias. Se pararmos para pensar em quanto tempo perdemos aprendendo o novo vamos
que isso se torna improdutivo. Por isso acredito que jogar fora o conhecimento de SQL que é justamente a linguagem mais difundida de banco de dados é como dar um tiro no pé. O ideal seria poder continuar usando o SQL
mas sem abdicar do novo. Poder usar SQL com OO. Pensando em termos de negócio se procurar alguém para ser contratado para nossa área veja quantos sabem SQL e quantos sabem HQL?
Acho que o novo deve ser testado e avaliado com certeza.
- Escolha da ferramenta/framework correto:
Já ouvi muito isso: “Usar um canhão para matar uma formiga.” A escolha depende muito do contexto do projeto. Depende se a empresa já usa uma tecnologia e não quer trocar. Se você tem a
abertura de testar e avaliar deve fazer isso com certeza. Não devemos ser muito religiosos a ponto de defender apenas uma ferramenta e não nos deixar avaliar outras.
- Configuração Programática x Configuração Annotation/XML
Não vejo diferença entre elas. As duas formas exigem que você aprenda ou sobre as anotações/XML ou sobre a API de configuração. Vejo apenas uma vantagem em configuração programática
em função de fazer com que suas classes de negócio sejam limpas e não dependam de tecnologia A ou B(classe de negócio com Annotation depende do jar das anotações). Com relação a desvantagem de
configuração programática existe o fato de que a cada nova mudança de configuração ela exige que o projeto seja recompilado e seja feito um novo redeploy.
- Troca de tecnologia as vezes é necessária
Com certeza a adoção de novas tecnologias em algum momento será necessária. Devemos trocar de tecnlogia apenas quando isso venha a trazer mais melhorias que possam resolver problemas
existentes ou que venha a nos acrescentar mais produtividade sem que com isso percamos o controle do que estamos fazendo. Já vi casos em fábricas de software em que a cada projeto novo se
adotava uma nova tecnlogia apenas como meio de aprendizado ou por modismo sem levar em consideração quanto tempo iria ser utilizada e quais os benefícios que ela irá trazer.
Não devemos nos fechar e simplesmente não aceitar que as coisas mudam. As vezes é preciso rever os conceitos.
- Clareza nas mensagens para o usuário do Framework
Quantas vezes já me deparei com framework’s ORM’s como o Hibernate que simplesmente nos lançam exceptions que não nos dizem onde está o problema. Quem aqui que nunca copiou e colou uma exception
do hibernate no google afim de descobrir o que significava que atire a primeira pedra. Enquanto isso deveria ser mais claro para o usuário do framework. Agora imagina se você não encontrou nada
sobre a exception no Google e ainda não tem os fontes do framework para fazer a indigesta tarefar de depurar para descobrir o que será que fez de errado. Ai como dizemos no trabalho: “Você tá na roça.”;
- Novas funcionalidades
Sejam bem vindas. Desde que não sejam impostas e que se possa optar por usar ou não. Funcionalidades no caso do Hibernate como deleção em cascata, lazy load, lock, etc não são de uso obrigatório. Por
isso se achaemos que perdemos o controle fazendo uso dessas funcionalidades basta não usá-las e fazer isso programaticamente sem automação. As funcionalidades que geram produtividade sem
perca do controle e que sejam intuitivas a ponto de nos dizer o que está dando errado quando ocorre algum problema sempre serão bem vindas.
- Complexidade X Flexibilidade
Que todo sistema começa simples e se torna complexo isso é o padrão. Pois sempre vão ser acrescentadas novas funcionalidades no sistema. Agora o que não pode é se tornar complexo e dificil de
manter. Isso ocorre também na escolha de um framework ORM. Quem é que não quer novas funcionalidades? O que ningúem deseja é que essas novas funcionalidades venham como dizem por ai a “engessar” o uso
fazendo com que se torne complexo e muito menos flexível.
- Cache
Essa é uma funcionalidade interessante em frameworks ORM como o Hibernate. Ela só deixa de ser interessante quando ouvimos dizer que o Hibernate não gerou o melhor SQL mas conseguiu suprir essa
deficiência usando um Cache. Isso no meu modo de ver é uma adequação ténica e não realmente uma melhoria como uma funcionalidade. A coisa complica mais um pouco quando se usa o cache de segundo nível.
Até parece a web, onde criou-se originalmente o HTML e desde então vem sendo feitas novas adequações técnicas(gambiarra) em camadas. Ex: html, jsp, asp, dhtml, xhtml, flash, applet, etc,etc. Talvez com HTML5
isso melhore.
Como todo mundo aqui disse o que pensava o no final querendo se esquivar disse “Isso é apenas minha opinião pessoal.”. Eu também não poderia deixar de dizer “Isso também é minha opinião pessoal”.
Vamos deixar aqui então um questionamento que acho que devemos fazer. Qual seriam então os requisitos ideias para o framework que tanto procuramos, que atenda gregos e troianos?
Fica aqui minhas sugestões ou necessidades para tal framework:
- Possibilidade de trabalhar com SQL e OO sem ter que aprender uma nova linguagem e abandonar o que já sabemos;
- Ter funcionalidades como delete cascade, lazy load, transações, lock, cache, etc sem criar mais complexidade;
- Permitir fazer select’s de objetos de forma parcial permitindo que o programador traga via SQL apenas os objetos que lhe interessam na árvore do objeto do principal Ex: trazer apenas nome da cidade no Objeto cidade de uma pessoa já que preciso apenas disso para apresentar na view. O Hibernate sempre vai trazer o objeto completo. Em muitos casos não precisamos dessa abordagem. O Objeto principal queremos de forma completa mas os relacionamentos normalmente precisamos mostrar apenas uma outra propriedade;
- Permtir configuração tanto via anotação/xml como programáticamente;
- Permitir que novas funcionalidades sejam opcionais e não impostas;
- Facilitar configuração dos relacionamentos. (Quem aqui que nunca se confundiu qual anotação usar OneToMany ou ManyToOne???
- Facilidade de Integração com outros frameworks como Spring, Guice, etc. Trazer exemplos disso ou ferramentas que façam isso;
- Ferramentas(plugins) que facilitem a criação de novos projetos usando o framework pois não temos obrigação de saber configurar tudo isso sozinho e nem advinhar como foi feito;
- Ferramentas(plugins) que permitam executar SQL’s e ver os objetos retornados e não o resultset. Permitindo navegar e inspecionar tais objetos sem ter que necessariamente
fazer uma aplicação para isso. Quem aqui que nunca fez um HQL sem saber se o resultado seria o desejado e teve que executar várias a aplicação pra ver como isso comporta.
(Hibernate tem HibernateTools que nos mostra os objetos mas não tem como ver as propriedades dos mesmos além de que diz que suporta querys nativas
mas no plugin não permite usar sql e sim somente HQL e critéria). Talvez tenha query nativa somente para dizer que tem;
- Ferramentas(plugins) que permitam editar configurações de forma visual o que torna mais produtivo;
- Ferramentas(plugins) que permitam fazer engenharia reverso do banco com interação do usuário para resolver problemas como mapeamento de herança e não gerar o modelo simplesmente como tá no banco;
- Criar expressões para compor um SQL de forma que possamos por exemplo usar um nome de função igual pra todos os bancos e quando for executar trocar a expressão pela função nativa do banco.
Permitindo com isso que tenhamos de certa forma uma maneira de melhorar a portabilidade. Isso também poderia se aplicar a sugestão de indices no sql o que melhora a performance mas que
tem sintaxe diferente em bancos de dados diferentes. Fazendo com isso que consigamos melhorar a portabilidade e performance sem perder o controle;
- Ferramenta(plugin) que permita comparação entre o modelo OO e o banco e aponte as diferenças visualmente;
- Ferramenta(plugin) que permita edição SQL com auto complete de todos objetos do modelo de negócios;
Espero que possamos continuar a discussão e que vocês também possar colocar aqui o que esperam de um framework ideal para persistência.
:thumbup:
Edson Martins
Gerente de Tecnologia
A.J.Rorato
edson@ajrorato.ind.br
