Pra quê um monte de DAOs cheios de métodos?

Rodrigo, porque você não cria um único Dao, que faça todas as operações de CRUD, salvar, atualizar, listar e carregar pelo identificador (poderia até ter buscar por exemplos). Aí quando você precisar de uma busca específica, cria um DaoEntidade com essa busca, mas deixa os CRUD lá no CrudDao, ou seja lá o que ele for.

Essa validação que você esta fazendo é desnecessária, se o objeto não puder ser persistido pelo Hibernate, ele vai lançar uma exceção.

Eu não vi nenhuma transação sendo aberta e terminada no seu código, ele está fazendo alguma atualização no banco de dados? Ele está funcionando?

Evite usar o flush(), o Hibernate sabe quando ele deve enviar os dados pra uma tabela e só vai fazer isso quando for estritamente necessário, diminuindo o gasto com banda de rede.

fabgp2001 wrote:Agora CV oque tu acha de tudo que ta sendo falado por aqui?

Eu acho que eu ja disse o bastante aqui, ou faltou alguma coisa?

JavaEvangelist Membro desde: 07/06/2005 12:01:01 Mensagens: 316 Offline

Maurício Linhares wrote:Rodrigo, porque você não cria um único Dao, que faça todas as operações de CRUD, salvar, atualizar, listar e carregar pelo identificador (poderia até ter buscar por exemplos). Aí quando você precisar de uma busca específica, cria um DaoEntidade com essa busca, mas deixa os CRUD lá no CrudDao, ou seja lá o que ele for.

Acho que não seria válido ter apenas um Dao q fizesse o CRUD de todas as tabelas, eu prefiro ter um Dao(desde que esse fique bem enxuto) pra cada tabela do jeito q está, por questão de arquitetura e tals.

Maurício Linhares wrote:
Essa validação que você esta fazendo é desnecessária, se o objeto não puder ser persistido pelo Hibernate, ele vai lançar uma exceção.

Eu faço essa validação para ter certeza que no DaoUsuario(exemplo) estará sempre passando o BeanUsuario, assim ele nem chegará nessa exceção que o hibernate mandaria e creio que fica mais seguro a nível de programação.

Maurício Linhares wrote:
Eu não vi nenhuma transação sendo aberta e terminada no seu código, ele está fazendo alguma atualização no banco de dados? Ele está funcionando?

Sim está fazendo o CRUD certinho, para controle de transação fiz uma classe que cria apenas uma única transação para todo(s) o(s) negócio(s), eu a chamo na ultima camada do sistema, exemplo

Com o código acima usa vários regras(e consequentemente vários daos) e se acontecer alguma exceção dou um rollback, estando tudo ok comito a transação ai ele salva no banco, por enquanto ainda não estou usando o JTA(fiz a classe de transação na unha mesmo).

Maurício Linhares wrote:
Evite usar o flush(), o Hibernate sabe quando ele deve enviar os dados pra uma tabela e só vai fazer isso quando for estritamente necessário, diminuindo o gasto com banda de rede.

Blz valew pela dica.

Ah e sobre as consultas específicas pra cada entidade já resolvi o problema, implemento no Dao uma interface com os métodos a mais. heheh

Falow!

Sem mais, Rodrigo.

Se você vai fazer um Dao Crud pra cada entidade, porque não faz a validação no próprio parâmetro?

Fica muito mais limpo e dá um bom motivo pra se ter vários Daos fazendo CRUD do mesmo jeito. Do jeito que você está fazendo tá só duplicando código.

JavaEvangelist Membro desde: 07/06/2005 12:01:01 Mensagens: 316 Offline

Maurício Linhares wrote:Se você vai fazer um Dao Crud pra cada entidade, porque não faz a validação no próprio parâmetro?

public void salvar (Usuario usuario) public Usuario carregar (Integer id)

Fica muito mais limpo e dá um bom motivo pra se ter vários Daos fazendo CRUD do mesmo jeito. Do jeito que você está fazendo tá só duplicando código.

Não véio acho que vc não entedeu(ou eu não expliquei direito), criei um Dao pai(classe abstrata) onde ele provém as ações CRUD para os restantes dos Daos filhos, não estou duplicando(ou sobrepondo) os métodos nos filhos, apenas o método que retorna o bean do Dao para validar posteriormente.

Sem mais, Rodrigo.

JavaEvangelist Membro desde: 07/04/2005 11:37:42 Mensagens: 328 Offline

Eu realmente gostei dessa idéia de daos genéricos com o hibernate.

Por um lado, mata um padrão, que é ter um dao para cada entidade, por outro, é mais inteligente e nao traz duplicacao de codigo!

E eu estava pensando um pouco (perdoem-me a inexperiencia): será que realmente é possível ter uma camada de persistencia totalmente flexivel, em que, apenas implementando novos daos eu consiga mudar a persistencia, sem ter que alterar as classes que usam os daos?

Pois, afinal, por exemplo, se eu quero uma consulta um pouquinho mais complexa, tenho que usar sql ou hql. Mas, e como faria as consultas complexas persistindo em arquivos binarios? E em xml´s? E em prevayler?

Enfim, o q acham?

Rapaz, "totalmente" nunca iria ser possível, mas com os vários DAOs (um pra cada entidade) seria mais fácil. Só que ao mesmo tempo também seria mais trabalhoso.

Se isso for uma necessidade do sistema (possibilidade de transitar entre vários sistemas de persistência) , vale a pena gastar tempo e código, se não for, pra quê perder tempo?

Os bancos de dados relacionais não vão sair de linha nem tão cedo, dá uma testada num banco OO ou em um que persista em XML e você vai ver o que é viver na idade da pedra, especialmente quando alguém pedir pra você fazer um agrupamento de informações ou um relatório

carneiro wrote:E eu estava pensando um pouco (perdoem-me a inexperiencia): será que realmente é possível ter uma camada de persistencia totalmente flexivel, em que, apenas implementando novos daos eu consiga mudar a persistencia, sem ter que alterar as classes que usam os daos?

Olá,

Cara essa semana eu acabei de fazer uma migracao dessas, tenho uma arquitetura que usei pra alguns desenvolvimentos que fiz. Minha persistencia e controle de transacoes era feito pelo Hibernate. Acabei de migrar pra usar o Spring, enviei pra um cliente e nao mudei uma linha de codigo do que tava la. Ou seja, enviei um novo jar da minha arquitetura e pedi pro cliente restartar o container web, so isso.

Na minha opiniao da sim, so que nem sempre vale a pena o esforco. Só se isso é um requisito senao esqueca.

]['s

Notícias, artigos e o maior fórum brasileiro sobre Java