Hibernate, o assunto era Reinventar a roda, mas isso não tem mais importância

Assuntos Gerais
#81

No caso do Hibernate.

Você cria um sistema de gerenciador de entidades, isso se estiver trabalhar com JPA por baixo, ou cria um sistema de gerenciador de sessão, se não estiver trabalhando com JPA por baixo.

SessionFactory ou EntityManager

Daí fazemos o seguinte, com o JDBC padrão criamos então a nossa classe de conexão que obtemos a instância de um DriveManager

depois disso tratamos os eventos em DAOs (Data Access Object), geralmente usamos da seguinte forma, para cada tabela (classe ou entidade como queira chamar) declaramos um DAO. Temos portanto na nossa aplicação:

Voltando ao hibernate.

Crio um JPAUtil, ou simplesmente um DAO genérico, do qual posso abstratir as funcionalidades de Cliente, Dependente, Usuario, Produto, Fornecedor e Log.

Bom. Fazemos nossas entidades herdarem uma classe model em comum, dessa forma tornamos generico o processo de CRUD e de outras atividades.

:arrow: E se mudar o banco??

Mudando o banco, em tese apenas precisamos mudar a nossa configuração inicial, que pode estar declarada em um hibernate.cfg.xml, em um persistence.xml, em um arquivo properties, podemos “dá um overring” nas configurações em runtime, em fim, temos essa liberdade de tratar e alterar a configuração.

:arrow: E se eu quiser usar SQL nas consultas?

Pode-se fazer, apesar que perde inclusive um dos conceitos fundamentais do hibernate ou iBATIS que é a crossover plataform. Independência de banco de dados.

:arrow: Posso fazer qualquer tipo de consulta?

Pode sim, basta saber criar os relacionamentos, usar a Criteria, find, Criterion, NamedQueries, em fim, usar o que o hibernate disponibiliza para você.

:arrow: E se mudar um campo da tabela?

Como você não tem toneladas de DAOs o seu impacto será MUITO menor que se você estivesse usando o padrão normal JDBC.

Em fim, há frameworks que vêm para ajudar e outros que concordo que só são para…

#82

O que eu vejo acontecer no mundo OS é que se o Zé das Couve precisa de uma funcionalidade não diponibilizada pelo framework “Tilanga”, ele vai lá e cria o framework dele, ao invés de entender a “Tilanga” e contribuir para o seu desenvolvimento.

Cria as variedades, mas ‘afasta’ a comunidade. Enfim, uma faca de dois legumes. (;

#83

Mas é complicado de se implementar um framework fácil de se extender. Você pega o Spring MVC mesmo, ele é extremamente extensível, mas entender ele é complicado pra quem só mexeu com frameworks action comum, só de ver a quantidade de controllers que estão disponíveis pra serem utilizados o cara se assusta.

#84

Mas isso ocorre ao meu ver porque nunca existe/existirá um concenso sobre algo, uma funcionalidade crucial para você pode parecer banal para os outros e é aí que começa a briga. Um exemplo, se todo mundo gostasse de struts não teria porque o Sergio criar o Mentawai, mas ele viu deficiencias no struts e as implementou no mentawai, assim como o próprio tem suas deficiencias em relação ao struts. É por isso que eu defendo que os frameworks devem ser extremamente plugáveis e polimórficos. Mas como fazer isso? Essa é uma boa questão mas talvez algo como é no eclipse, você adiciona suporte ao que você quer apenas.

#85

Olha, lá em “Design Patterns” os caras já avisavam que criar código orientado a objetos era difícil e mais difícil ainda era criar código flexível orientado a objetos, isso não é uma coisa trivial de se fazer não e quando você consegue isso em Java ou é a custa de muita mágica ou de interações complexas demais entre os objetos.

Pegue JSF por exemplo, ele é tão extensível que chega a ser absurda a complexidade de se criar componentes (hoje já existem frameworks pra se criar componentes em JSF!), a complexidade e flexibilidade demasiadas tornaram o framework complexo demais.

Flexibilidade é uma coisa que tem que ser medida com muito cuidado, especialmente em aplicações Java onde a própria linguagem não ajuda muito você a fazer esse tipo de coisa.

#86

Sim, mas veja o exemplo do struts, ele vem com o básico e oque você quiser você adiciona através de plugins… é disso que eu estou falando se eu não quero uma determinada funcionalidade eu não preciso usá-la ou sequer tela em meu projeto. Isso é flexibilidade e isso é um incentivo para se criar novas funcionalidades, poxa o struts não deixa fazer aquilo, mas eu posso criar um plugin e plugá-lo, mas nem todo mundo pensa assim entendeu, cria-se frameworks sem analizar a sua expansibilidade. Em resumo acho que frameworks deveriam ter o mínimo de funcionalidades e serem plugáveis…

#87

Mas aí mata o que você disse antes, veja só:

O WebWork fazia o que o Struts fazia e era melhor, tinha o esquema de interceptors e ainda tinha injeção de dependências direto no framework, porque então foram fazer Spring MVC, Mentawai e todo o resto se eles não faziam nada de diferente?

Eu, pessoalmente, não lembro de ter utilizado um framework Java que não fosse ao menos “levemente” extensível, por plugins, configuração ou coisas do gênero, o que não existe (e nunca vai existir) é um jeito padrão de se colocar plugins num framework, porque cada um tem o seu próprio domínio e “jeito” de se fazer as coisas.

Qual framework Java você usou não é plugável o suficiente? O que era que você queria?

#88

O caso é quando um framework/biblioteca que parece fazer a mesma coisa que um já existente, mas na verdade tem um propósito diferente.

Ex: O nosso Hibernate (caraca se contarmos as vezes que foi mencionado só neste tópito …) e o iBATIS. São frameworks ORM que tem propósitos diferentes.

O iBATIS é mais facil para trabalhar com o Banco legado com estrutura bem tosca ou se você já tem uma aplicação cheia de SQLs nos DAOs mas quer retirar esses SQLs do .java e colcoar em um arquivo XML separado e retirar os 1000 comandos set que estão sendo usados para popular os objetos.

Em uma aplicação dessa já pronta, aplicar o hibernate é muito mais complicado e o iBATIS pode ser uma alternativa bem interessante para melhorar a bagunça.

#89

Beleza, mas porque não incorporar essas funcionalidades ao hibernate? como se fosse um plug-in. tem tanto framework que fica dificil lembrar a sintaxe de todos.

#90

Porque esse não é o objetivo do Hibernate e isso sempre foi deixado bem claro. Se você não tem um modelo “redondinho” no banco de dados, não use Hibernate.

Quem tenta agradar todo mundo, termina não agradando ninguém.

#91

[quote=Maurício Linhares]Porque esse não é o objetivo do Hibernate e isso sempre foi deixado bem claro. Se você não tem um modelo “redondinho” no banco de dados, não use Hibernate.

Quem tenta agradar todo mundo, termina não agradando ninguém.[/quote]

Concordo demais com isso, faz bem manter o foco / propósito.

#92

Hibernate é sim uma reinvenção da roda…

Mas é uma roda aro 20, de liga leve, diamantada, e com pneus yokohama… :smiley:

#93

A idéia é componentizar as coisas, eu tenho um framework para aplicações web, se eu quiser usar uma ferramenta ORM eu baixo o plugin ORM desse meu framework, se eu quiser usar freemarker ao invés de jsp eu baixo o plugin que faz isso, se não existir eu leio a especificação e o desenvolvo mas tem um único core controlando tudo, desde injeção de objetos a configurações. Não sei se isso se aplica ao hibernante, mas talvez algo assim, se eu quisesse HQL eu baixaria o plugin para HQL no hibernate, se eu quisesse usar Lazy Load eu baixaria o plugin para lazy load…

Acho que é mais ou menos isso…

Acho que caminhariamos mais rápido nas evoluções…

#94

Mas existem coisas que são intrínsecas do framework, o Hibernate não poderia existir sem lazy-loading e sem HQL, não adianta ter um framework que não faça nada sozinho, o básico da funcionalidade dele tem que estar implementada (que no Hibernate, por exemplo é fazer CRUD, poder fazer selects sem usar SQL, usando HQL e criteria, e ter lazy-loading de entidades sempre que necessário). O que for além disso é complemento.

No Spring MVC, por exemplo, quando você quer usar o freemarker, basta trocar uma linha de configuração lá dizendo que o seu controller usa o freemaker, ele já sabe o que você vai fazer. Se você não vai usar FreeMaker, Velocity ou JSP com JSTL (que são os que já vem com plugins por padrão no Spring MVC) você pode escrever o seu próprio plugin pra sua própria engine de template e dizer pro Spring MVC qual é a classe que gera as views. Ele é totalmente configurável e extensível, não só pra isso como pra muitas outras coisas.

Ainda não consigo entender o seu ponto, qual o framework que você achou que não era extensível o suficiente pro seu problema?

#95

desculpem em desvirtuar o assunto do topico… mas apos ler alguns posts fiquei com uma grande curiosidade que aposto que muitos devem ter ficado… o que são reads phantom? pq abrir uma transação pra fazer select???

#96

[quote=Maurício Linhares]Olha, lá em “Design Patterns” os caras já avisavam que criar código orientado a objetos era difícil e mais difícil ainda era criar código flexível orientado a objetos, isso não é uma coisa trivial de se fazer não e quando você consegue isso em Java ou é a custa de muita mágica ou de interações complexas demais entre os objetos.

Pegue JSF por exemplo, ele é tão extensível que chega a ser absurda a complexidade de se criar componentes (hoje já existem frameworks pra se criar componentes em JSF!), a complexidade e flexibilidade demasiadas tornaram o framework complexo demais.

Flexibilidade é uma coisa que tem que ser medida com muito cuidado, especialmente em aplicações Java onde a própria linguagem não ajuda muito você a fazer esse tipo de coisa.[/quote]

O Hibernate é um bom exemplo de framework extensível no qual boa parte da extensibilidade fica escondida do usuário comum. É possível customizar todas etapas do ORM e para quem usa não muda nada. Plugins não são necessáriamente a resposta para extensibilidade e ser composicional.

#97

[quote=volnei]A idéia é componentizar as coisas, eu tenho um framework para aplicações web, se eu quiser usar uma ferramenta ORM eu baixo o plugin ORM desse meu framework, se eu quiser usar freemarker ao invés de jsp eu baixo o plugin que faz isso, se não existir eu leio a especificação e o desenvolvo mas tem um único core controlando tudo, desde injeção de objetos a configurações. Não sei se isso se aplica ao hibernante, mas talvez algo assim, se eu quisesse HQL eu baixaria o plugin para HQL no hibernate, se eu quisesse usar Lazy Load eu baixaria o plugin para lazy load…

Acho que é mais ou menos isso…

Acho que caminhariamos mais rápido nas evoluções…[/quote]
LAZY e HQL a parte??? Você compraria um carro sem volante? e uma bicicleta sem roda?

#98

[quote=bobmoe]
LAZY e HQL a parte??? Você compraria um carro sem volante? e uma bicicleta sem roda? [/quote]

Infeliz comparação, não se dirige um carro sem volante, mas se faz grandes coisas sem lazy load, e tambem existe a critéria que pode ser usada no lugar da HQL. Pra ser irônico tem que no mínimo saber oque está falando.

#99

[quote=volnei][quote=bobmoe]
LAZY e HQL a parte??? Você compraria um carro sem volante? e uma bicicleta sem roda? [/quote]

Infeliz comparação, não se dirige um carro sem volante, mas se faz grandes coisas sem lazy load, e tambem existe a critéria que pode ser usada no lugar da HQL. Pra ser irônico tem que no mínimo saber oque está falando.[/quote]
é justamente o contrário: difícilmente se faz grandes coisas sem Lazy Load :slight_smile:
não da pra complicar a vida da maioria, só pq a excessão não usa isso, entende? enquanto alguns indivíduos que não usam perdem, no geral o coletivo se beneficia.

#100

criteria sim e algo inutil ao meu ver…