Criterio em DAO

O problema de performance não é relativo ao uso de memoria por 1 field a mais, mas sim por buscar muito mais informação que o necessario no banco de dados.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Entendi.
O problema não é a estrutura de objetos em si (desde que não instanciamos todos os objetos agregados!), mas a recuperação dessas informações do banco de dados.

E a separação de lógica de dados e de negocios, alguma opiniao.
Como voces fazem, o que acham que deve ser feito.
É valido ter uma classe apenas para delegar para o DAO.
ex:

Pelo que sei devemos seperar dados de negócios.

Que eu saiba, temos que separar a camada de acesso aos dados do negocio. Dados e negocio quanto mais junto melhor.

Voce pode ter um método cadastrar em Funcionario que valida tudo e termina mandando o dao salvar ele.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Podemos trocar o nome da classe por:
Funcionarios (no plural).

Veja que aqui eu tenho.
- cadastre um funcionario
é diferente de
- funcionario.cadastra-se

Mas ai vamos entrar um discussao antiga.

E o que eu quero saber mesmo é:
Fica embassado colocar a validaçao no DAO.

O problema é se em outra regra de negocio eu quiser inserir um funcionario também.
Eu faco pelo DAO ou pela regra de negocio ?
Para mim tem que ser pela regra.

This message was edited 1 time. Last update was at 18/04/2005 16:37:18

O DAO não vai ter regra alguma, nunca jamais, senão você vai diminuir o reuso dele em muito.

Que tal o seguinte exemplo:

Pronto, o DAO só faz oque precisa, funcionario só faz oque precisa e teus use cases não furam os layers da aplicação.

jprogrammer wrote:
E o que eu quero saber mesmo é:
Fica embassado colocar a validaçao no DAO.

De uma maneira geral, eu estabeleço no meu DAO um contrato de que a ivnariante do objeto vai estar cumprida, ou seja: todas as associações obrigatórias são satisfeitas e os atributos estão dentro do válido.

O DAO coloca no SGBD (com ajuda de outros, quase sempre) esses relacionamentos e (dependendo do caso), checa se os outros estão preenchidos (quando é só um valor, null basta, quando é uma relação com outra tabela, tem que checar qual registro apontar).

jprogrammer wrote:
O problema é se em outra regra de negocio eu quiser inserir um funcionario também.
Eu faco pelo DAO ou pela regra de negocio ?
Para mim tem que ser pela regra.

Pera. Outra regra de negócio não, você processa TODAS as regras de negócio no seu POJO e depois manda o DAO pegar aquele objeto e enfiar no SGBD. Acho que você está confundindo esse passo, não

?

O que pode acontecer é a criação de alguns métodos de conveniência. Se, por exemplo, você vai atualizar quinze mil objetos em banco, se puxar um a um, atualizar e persistir vai gastar tempo e memória a toa. Você pdoe criar um método no DAO que faça isso via SQL, te poupando muito tempo e esforço

Entretanto, você deve ter essa função na sua camada de negócios. por exemplo, eu teria um método num objeto de negócios como qualquer outro, mas na verdade ele chama o DAO

This message was edited 1 time. Last update was at 18/04/2005 16:53:33

Então eu poderia ter os métodos relacionados a uma funcionario no proprio pojo e poderia ter uma classe para metódo de negocios coletivos para vários funcionarios.
ex:

Sim, mas é claro que com cuidado. Você estará jogando fora a segurança de um modelo de objetos por performance, e cabe julgar o custo/benefício.

O maior deles é que você deveria ter um meio de avisar às instâncias já existentes de funcionário que elas estão defasadas, e isso pode ser bem complicado (mais um motivo para usar DAOs em sistemas simples, não necessariamente pequenos, mas simples).

This message was edited 1 time. Last update was at 18/04/2005 17:02:40

Sim, existe até um padrão para isso, que é o Table Data Gateway. Que é tratar uma coleção de objetos como uma entidade só.

No caso do teu sistema realizar muita atualização em massa, vale a pena usar isso e criar um POJO que representa um conjunto de entidades de maior granulosidade.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Mas em que caso uma classe defasada pode atrapalhar.
Eu busco os objetos e trabalho com o que estiver na memoria.
Se outro usuario atualizou ai cabe a implementacao de mecanismos no sistema. Mas acredito que isso é feito em nivel de GUI.
Pensar isso na estrutura é ficar louco.

Outra duvida, vamos imaginar uma sistema de ponto eletronico
ex:

Isso é adequado.
Esse método depende de varios funconarios.
Agora é melhor eu ter essa classe ou criar um metodo.
funcionario.apontar();

É um processo complexo que depende de inumeras entidades.
Não é melhor deixar com o funcionario apenas os metodos ligados diretamente a ele.

outro exemplo

É adequado ou não colocar no pojo um método que acessa dados persistidos.

Ou você está sem pontos de interrogação ou eu não entendi nada

Se você tem mais de um usuário manipulando um universo de objetos, ou você tem um jeito de notificar a todos da mudança que um faz ou você pode ter inconsistência...

Mande o OO pra bem longe e use uma solução prática. Não compartilhe seus objetos de domínio entre transações/use cases e confie no seu banco de dados para controle de concorrencia.

This message was edited 1 time. Last update was at 18/04/2005 17:38:19

Desculpa pelos ??????
Tira o sentido da frase.

Enquanto a notificação de objetos.
Qual framework faz isso ?

Enquanto a segunda pergunta vou simplifica-la.
É adequado um pojo buscar dados persistidos de entidades que não sejam ele mesmo ?
ex:

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