fritei o cerebro com tudo isso…
hehheheh
:-o :mrgreen: :-o :mrgreen:
[quote=Kleber Santos]fritei o cerebro com tudo isso…
hehheheh
:-o :mrgreen: :-o :mrgreen: [/quote]
Normal, o GUJ faz isso com agente :mrgreen:
verdade Marcelo…
mas no fundo, no fundo mesmo amigão
Amuuuu fritar o cerebro
:mrgreen: :mrgreen: :mrgreen:
Eu héin?! :roll:
[quote=Kleber Santos]verdade Marcelo…
mas no fundo, no fundo mesmo amigão
Amuuuu fritar o cerebro
:mrgreen: :mrgreen: :mrgreen: [/quote]
Marcelo :?:
Olá,
O impressionante dessas discucoes, fora tudo que o CV ja falou, é que tudo que é levantado é implementado pelo Hibernate.
Tem respostas que leio e fico pensando, será que ele ta falando isso e nunca olhou o Hibernate.
Eu sei que ele nao é perfeito, mas até agora nao conheco nada melhor para o que ele se dispoe. Abstrair bases de dados e mapeamento O/R.
Esse tipo de frase o CV deve pensar na hora que ta bebendo “in london”, nao é possivel.
:mrgreen:
]['s
[quote=fabgp2001]
Esse tipo de frase o CV deve pensar na hora que ta bebendo “in london”, nao é possivel.
:mrgreen:
]['s[/quote]
Como assim, “não é possível”?
Fabio, apesar de concordar com o carlos ainda nao entendi como o Hibernate eliminaria DAOs, varios metodos de pesquisa, etc. Pdoeria dar um exemplo?
Shoes
Eu acho que colocar o hibernate em uma camada abaixo dos DAOs não é problema nenhum.
Achei bem legal os itens que o CV colocou, pois na prática temos que simplificar mesmo.
Mas abstrair é bom para ter reuso de código e facilitar implementações futuras. Fazer rafactory sempre dá trabalho, então tentar ter uma arquitetura que facilita de uma forma cada vez maior novas implementações e o reuso.
É lógico que como o CV falou: Ficar mais de 30 minutos para decidir em projeto a arquitetura de uma DAO é inviável.
Mas como estamos no GUJ é sempre bom discutir, é para isso que ele existe.
Insisto no ponto de abstrair o Hibernate pois, mesmo usando-o, há várias formas de realizar uma mesma tarefa. Exemplo simples são as interfaces Query e Criteria.
É verdade LIPE, até para migração de versão de uma hibernate para outro. E manter uma padrão entre os desenvolvedores do projeto.
Hmm… discordo, Lipe. Quanto tempo demora pra mudar o codigo caso vc perceba que usar a Query API nao foi uma boa ideia pq agora vc tem um novo requisito doente que precisa da Criteria API de qualquer jeito?
E, mesmo assim, fica tao feio usar as duas APIs ao mesmo tempo? Ta tudo no Hibernate, afinal…
[quote=cv]Hmm… discordo, Lipe. Quanto tempo demora pra mudar o codigo caso vc perceba que usar a Query API nao foi uma boa ideia pq agora vc tem um novo requisito doente que precisa da Criteria API de qualquer jeito?
E, mesmo assim, fica tao feio usar as duas APIs ao mesmo tempo? Ta tudo no Hibernate, afinal…[/quote]
Pois é, pra fazer uma pesquisa que já está definida, usa uma named query mesmo, lá no mapeamento, pra montar uma query em tempo de execução, usa criteria, que facilita e ainda facilita ainda mais pra trocar de banco de dados.
cv, não é uma questão de tempo. Como disse, o problema está em mudar o código do cliente.
As classes que chamam métodos na camada persistência não deveriam se preocupar como diabos está programado para devolver uma lista de pessoas ao fazer camadaDePersistencia.pessoasByAge( int age ).
[quote=pcalcado]Fabio, apesar de concordar com o carlos ainda nao entendi como o Hibernate eliminaria DAOs, varios metodos de pesquisa, etc. Pdoeria dar um exemplo?
Shoes[/quote]
Shoes,
Desculpa a demora em respodner, mas vamos a minha opiniao.
O que eu preciso em uma classe de persistencia para uma classe de negocio?
Metodos que facam o CRUD e metodos de pesquisa que sao expecificos para cada Entidade.
Entao os metodos Save, Update (ou um unico SaveOrUpdate) e um Delete sao iguais para todas entidades. Aqui acho que todas entidades podem usar a mesma classe para essas operacoes. Os metodo find, findAll, ect (cada um nomeia de um jeito) só diferem no criterio de busca, ou seja, se tu tem classes de Query e/ou Criteria tu nao precisa ficar criando classes distintas para tratar isso tb é so tem um um metodo find recebendo o criterio de busca e pronto.
Pensando assim, pq eu preciso fazer um DAO para cada classe duplicando metodos? É nesse ponto que eu digo que o hibernate implementa e facilita. Ja vi varias discucoes aqui sobre DAO’s e a discucao corria sempre no mesmo assunto, fazer classe expecifica, ou classe generica, como fazer as consultas, etc. Eu nao acho que tratar assim, os metodos basicos em uma unica classe seja generalizar, a meu ver é simplificar, nao duplicando codigo e ficando somente a parte de consulta (Query e Criteria) como parte expecifica para cada entidade e essa sim voce tera que separar, aqui eu ja trabalhei com ValeuListHandle principalmente quando preciso paginar o retorno, aqui tb utilizo as facilidades do Hibernate para isso.
Desse modo só funciona se eu usar algum framework O/R que me provenha estas facilidades, se eu for partir para fzar tudo na mao provavelmente nao conseguirei fazer desse modo, provaevelmente terei que criar classes expecificas para cada entidade ou reiventar a roda escrevendo um novo framework O/R que atenda as minhas necessidades, mas ai será que vale a pena? E é nesse ponto que eu digo que o Hibernate implementa tudo, ele nao é perfeito mas fora situacoes especificas o resto ele comtempla.
Fora isso tem a parte que o CV comentou, cache, transacao, api de consulta, sistema para paginação, etc tudo sao providos pelo Hibernate.
O que voce acha?
]['s
[quote=LIPE]cv, não é uma questão de tempo. Como disse, o problema está em mudar o código do cliente.
As classes que chamam métodos na camada persistência não deveriam se preocupar como diabos está programado para devolver uma lista de pessoas ao fazer camadaDePersistencia.pessoasByAge( int age ).[/quote]
Eu concordo com o LIPE quando se trata de um produto, muitas vezes o produto fica em uso por anos e é sempre bom ter uma facilidade para mudancas na parte de infra do sistema sem ter que mexer no core da aplicacao.
]['s
Se independência de ferramenta de mapeamento O/R for uma necessidade do sistema, vale a pena ter esse trabalho todo. Se não for, pra que se preocupar com isso?
O overengineering anda solto na comunidade Java :mrgreen:
Êpa…
Não falei em não usar Hibernate, IBatis ou Zahl-OR (e acho que esse não era o foco). DAOs não te impedem disso 
Então, acho que pelo que entendi você está propondo usar uma classe genérica ao invés de ter um DAO para cada entidade. Isso diminuiria a quantidade de classes mas não a quantidade de métodos de consulta.
De qualquer modo a princípio você pode reutilizar o mesmo DAO aproveitando a idéia original do Maurício com Specification pattern.
Eu pessoalmente acho que um Repositório para cada entidade tem mais valor no domínio.
Shoes
Você já tinha falado nessa história de repositório antes Phillip, como é que é isso?
[quote=pcalcado]Êpa…
Não falei em não usar Hibernate, IBatis ou Zahl-OR (e acho que esse não era o foco). DAOs não te impedem disso ;)[/quote]
Concordo e nem eu falei que nao precisa usar, só comentei que muita coisa do que era discutido ja é implementado pelo Hibernate (ou outro framework O/R decente). Por isso prefiro perder mais tempo discutindo assuntos que vao agregar mais valor.
Nao que eu estaja propondo uma classe generica, mas se meu save é igual para todas classes, pq irei escrever mais de um?
[quote=pcalcado]
De qualquer modo a princípio você pode reutilizar o mesmo DAO aproveitando a idéia original do Maurício com Specification pattern.
Eu pessoalmente acho que um Repositório para cada entidade tem mais valor no domínio.[/quote]
Vou da uma olhada nisso, mas ultimamente tenho usado (ou tentando usar) o ActiveRecord.