> Prefiro um projeto com prazo curto sendo desenvolvido usando o ORM > "xyz" do que sem nenhum ORM e strings de conexões espalhadas por todo > o código. >
Concordo, mas não precisa ser assim: depende do tamanho do projeto e da qualidade dos recursos humanos. Programadores *razoáveis* em Java conseguem entender a necessidade de fragmentar o código em classes (POO, afinal) de forma a distribuir as funções e comportamentos em classes distintas. Assim seria possível existir uma classe para realizar a conexão ao banco mesmo sem usar um framework ORM pronto. > Manter uma aplicação desenvolvida por programadores experientes usando > o ORM Open Source "xyz" é bem mais simples. Imagine ficar dependente > de um programador que criou e usou sua própria maneira mirabolante de > fazer as conexões no banco? Mesmo que esteja tudo documentado, de > início, apenas este saberá como as coisas funcionam. > Este assunto foi abordado na tese que defendi para minha especialização em Java. Até já cheguei a perguntar algo relacionado na lista [1] em relação aos frameworks ORM, mas não tive resposta (entendi, porque é um assunto bastante off-topic). Não existe regra para persistir objetos Java em SGBDR, mas as que eu mais vejo por aí são: SQL estático, DAO [2] e Hibernate (sendo mais chato ainda). O uso do Caché ou outras alternativas como DB4O considero promissoras, mas não confiáveis - vá mandar os consultores gerarem relatórios complexos com SQL depois de adotar esta tecnologia pra ti ver... Em projetos que já tive oportunidade de trabalhar e/ou pude visualizar, de alta complexidade, alta manutenção, e crescimento indefinido (sistemas bancários de bolsa de valores e DOC, por exemplo) a idéia de usar um JPA ou Hibernate nem passa pela cabeça dos arquitetos e dos gerentes de projeto. O que eu mais pude observar são frameworks de fabricação própria, muito bem documentados e funcionais, que atendem a necessidade dos projetos sem causar overheads e sem muita complexidade. Até frameworks escritos com o uso da API Reflections [3] eu já vi funcionarem muito bem de forma elegante. *Además*, para quem usou Hibernate desde as suas primeiras versões pôde perceber que a manutenção do ORM também não era tão fácil assim, devido ao excesso de arquivos XML. Hoje com o advento das _Annotations_ tudo ficou mais simples (!) mas ainda assim depende de conhecer muito bem o framework - ou a especificação JPA se for usá-la - para que tudo funcione de acordo. Para encerrar: como um programador/arquiteto Java eu apostaria em Hibernate ou alguma implementação da JPA apenas se a equipe de desenvolvimento estivesse muito bem munida de profissionais experientes nesta área. Ainda assim eu tentaria adotar uma solução personalizada e customizada que eu pudesse ter total controle do que ela faz. Nunca vi um projeto de grande escala baseado na JPA ou no Hibernate. [1] http://www.mail-archive.com/pgbr-geral@listas.postgresql.org.br/msg18619.html [2] http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html [3] http://java.sun.com/docs/books/tutorial/reflect/index.html -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
