Criterio em DAO

Se você tem um objeto Departamento dentro do funcionário, não vejo problemas em utilizar o ‘atributo do atributo’ (considerando que na tabela você teria essa estrutura também), como:

public class FuncionarioDAO(){ public Collection consultarById(Funcionario funcionario){ String sql = "SELECT * FROM FUNCIONARIO WHERE ID_DEPARTAMENTO = " + funcionario.departamento.getId() + "; } }

Aqui tem uma discussão mais ou menos acerca disso:
http://www.guj.com.br/posts/list/30/22420.java

Pode ser.
Mas não ficaria deselegante.
Ter que ficar instanciando a classe funcionario e subclasses para fazer uma consulta.
Estava pensando em algo como

public class FuncionarioDAO(){
    public Collection consultar(int numEdificio, char sexo){
       //
    }

    public Collection consultar(int numEdificio){
       //
    }
 }

olhando rapidamente, prefiro como o Rafael postou, me parece um pouco mais OO.
so tiraria o sql de detro do DAO.

[]'s

Bem, eu optaria por receber o objeto, porque passando parâmetros eu teria de ter um método pra cada parâmetro. E se eu tivesse 50, 100, 1000 parâmetros…
E como foi dito no outro tópico, não é interessante espalhar os dados da implementação do objeto por aí, seria legal se o DAO não conhecesse como é a implementação do Funcionario.(Se bem que passando o objeto, dentro dele ele acabaria sabendo que ele possui um atributo chamado Departamento que possui um id.)

olhando rapidamente, prefiro como o Rafael postou, me parece um pouco mais OO.
so tiraria o sql de detro do DAO.

E colocaria onde o SQL?Arquivos properties?

Compo vocês falaram se eu tiver muitos critérios tem problema.
É bom que fica bem mais flexivel da forma do Rafael.

Enquanto a sql não veria problemas…

sem usar frameworks, colocaria a principio em properties.
se as consultas se tornassem muito complexas, em xml’s

[]'s

Agora eu fiquei curioso, como você faria isso em xml´s?
É que nunca vi desta forma, só em properties.

To começando ficar interessado também.
Mas outra pergunta.

E no caso de consultas com:

• agrupamento
• com restrição de campos (apenas alguns campos da classe)
• campos nulos (ver se o campo é nulo em primitivos)

tem outras formas, mas eu ja fiz carregando as consultas do xml em beans e tenho uma classe metodos estaticos que me retornam essas consultas.
no xml fica com tags mais ou menos assim:

<consulta codigo="codigo1"
              sql="SELECT 1, 2 , 3 FROM table WHERE parametro1 = ?">
     </consulta>

usando PreparedStatement vc substitui os parametros.
é por ae…

[]'s

<EDIT>
claro que depende das consultas, nesse caso eu tinha consultas bem chatas, que em arquivos properties ficariam dificeis de manter.
</EDIT>

Eu precisaria criar um método de consulta para cada consulta diferente?
Por exemplo:

public Collection consultarById(String query){...} public Collection consultarBySexo(String query){...} public Collection consultarByIdade(String query){...}

Não tem alguma forma de abstrair mais essa consulta, ou seria melhor mudar toda parte de persistência para utilizar algum framework, como Hibernate?

jgbt, qual API vc utiliza para parsear os XML’s para seus Beans?

a ideia é essa, cada metodo deve fazer somente o que é responsabilidade dele.
ter um metodo generico, mas cheio de if’s p/ montar a consulta, não me parece legal.

eu usei o castor, um framework p/ xml, não lembro o linnk agora, mas da uma procurada no google que vc deve achar.

[]'s

jgbt:

tem outras formas, mas eu ja fiz carregando as consultas do xml em beans e tenho uma classe metodos estaticos que me retornam essas consultas.
no xml fica com tags mais ou menos assim:

<consulta codigo="codigo1"
              sql="SELECT 1, 2 , 3 FROM table WHERE parametro1 = ?">
     </consulta>

Não entendi qual a diferença de colocar uma consulta no XML ou em um properties. O que você ganhou com esse XML? (Além da necessidade de ter que fazer o parser! :))

[]'s
Marco Campêlo

é que eram comsultas complexas, com varias subqueries.
ficava ruim de visualizar a consulta em um properties, numa unica linha.
e o bean tinha outras propiedades alem da query, que ficavam facil de mofificar, sem recompilar o codigo.

[]'s

Se seus DAOs possuem tantos métodos de pesquisa diferentes que você está ficando maluco, considere seriamente a adoção de um framework O-R decente.

Eu já fui a favor de DAOs com “linguagens de consulta”, mas isso é completamente contra o uso que se deveria fazer de um DAO em si. Um DAO deveria ser usado quando você tem X consultas no banco, e no máximo, quem sabe, vai passar para 2X em alguns meses, mas não mais que isso. Uma das grandes vantagens (se você cosntruir DAOs bonitinhos) é que passar essa implementação para um Hibernate (exemplo, nenhuma lei) não é muito complicado mantendo a API do DAO.

Um outro ponto onde DAOs são problemáticos é montar relacionamentos. Muitas vezes voê acaba com métodos cheios de gambiarras para evitar trazer toda a sua estrutura de objetos do banco e ao mesmo tempo evitar NullPointerException.

Resumindo:

Use DAO quando você não vai rpecisar fazer nada além de CRUD. Se você precisa emitir relatórios ou fazer buscas complexas e parametrizadas, pode fazer com que estas operações com o SBD sejam efetuadas por outro componente, e deixem os DAOs no

public interface Dao{

 public void create(Object o);
 public Object read(int key);
 public void update(Object o);
 public void delete(Object o);

}

E meia dúzia de métodos de busca. Aliás: procure reutilizar o máximod e código dentro de um DAO, cuidade no modo como transforma um ResultSet em objeto, faça de maneira que todos os métodos de pesquisa possam reutilizar este método se possível.

Pessoal,

não sou nenhum conhecedor profundo sobre DAO's mas a interface que Shoes falor não poderia ficar assim :

public interface Dao{
 
  public void create(Object o);
  public Object read(int key);
  public void update(Object o);
  public void delete(Object o);
  public void relateObjects(Object oSouce, Object oDestination, String sRelation);
  public void unrelateObjects(Object oSouce, Object oDestination, String sRelation);
  public void save();

 }

onde os métodos de relate e unrelate fariam os updates da campos relacionados(chaves estrangeiras e primárias) e o método save salvaria tudo que estivesse pronto para salvar.
Poderíamos ter algo assim:

DAO.update(aluno);
  DAO.unrelateObjects(aluno, algebra,"aluno2disciplina ");
  DAO.relateObjects(aluno, calculo,"aluno2disciplina ");
  DAO.save()

Assim o médoto save no banco seria algo do tipo:

update table_aluno set ..... ;--Seta os campos 
update table_aluno set aluno2disciplina = null;--parte do relacionamento
update table_aluno set aluno2disciplina = 844558 ;-- um id de disciplina 
commit;

Acho que isso não deve estar muito bonito.
Como podemos tratar relacionamentos de forma correta ?? (sem utilizar hibernate :D ) .

Valeu pessoal

Olá,

Ssalgado:

não sou nenhum conhecedor profundo sobre DAO's mas a interface que Shoes falor não poderia ficar assim :

Na verdade, a "interface" era uma piada com o CRUD ;)

Ssalgado:

public interface Dao{
 
  public void create(Object o);
  public Object read(int key);
  public void update(Object o);
  public void delete(Object o);
  public void relateObjects(Object oSouce, Object oDestination, String sRelation);
  public void unrelateObjects(Object oSouce, Object oDestination, String sRelation);
  public void save();

 }

onde os métodos de relate e unrelate fariam os updates da campos relacionados(chaves estrangeiras e primárias) e o método save salvaria tudo que estivesse pronto para salvar.

Um DAO abstrato (ou uma interface) com métodos de negócio definidos não é muito útil, a menos que você goste de casts.

Ssalgado:

Poderíamos ter algo assim:

DAO.update(aluno);
  DAO.unrelateObjects(aluno, algebra,"aluno2disciplina ");
  DAO.relateObjects(aluno, calculo,"aluno2disciplina ");
  DAO.save()

Você tme um acoplamento de controle muito grande aí. Ao passar "o que deve ser feito" como um parãmetro, você prende a implementação do seu método no cliente, o que é bem ruim. Mais detalhes aqui.

Além do que, objetos sabem de uma relação através de seus atributos. Se você fosse implementar isso, o dao deveria saber que o aluno têm uma relação com cálculo, e quando necessário atualzar cálculo também.

O que não é muito prático dependendo do caso. Sem lazy loading você geralmente (como falei) vai ter vários métodos fazendo a mesma coisa, só que com mais ou menos detalhes, para não ter uma NPE.

Ssalgado:

Como podemos tratar relacionamentos de forma correta ?? (sem utilizar hibernate :D ) .

Com DAOs você não tem muita escolha, tem muitas gambiarras. O DAO é orientado por funcionalidade, então se eu preciso de um relacionamento para executar uma tarefa, mas em outra eu não rpeciso trazer este relacionamento todo (e isso pdoe envolver vários níveis), vou ter métodos diferentes que fazem quase a mesma coisa.

pcalcado:

Com DAOs você não tem muita escolha, tem muitas gambiarras. O DAO é orientado por funcionalidade, então se eu preciso de um relacionamento para executar uma tarefa, mas em outra eu não rpeciso trazer este relacionamento todo (e isso pdoe envolver vários níveis), vou ter métodos diferentes que fazem quase a mesma coisa.

Não existe nenhum padrão de projeto para acabar com este problema do DAO?

pcalcado:

Olá,

Você tme um acoplamento de controle muito grande aí. Ao passar “o que deve ser feito” como um parãmetro, você prende a implementação do seu método no cliente, o que é bem ruim. Mais detalhes aqui.

ae shoes,
não é a primeira vez que vc cita esse livro como refererencia.
ja to me coçando p/ comprar, vale a pena mesmo?

[]'s

maikonaraujo:

Não existe nenhum padrão de projeto para acabar com este problema do DAO?

Não que eu conheça.

O que você poderia tentar fazer é criar listeners e interceptadores (talvez suando metadados) que sabem quando o estado de um objeto foi significantemente alterado e o persista, e um mecanismo de lazy-loading com proxies dinâmicos.

Mas aí você cria um framework objeto-relacional

Definitivamnete, sim. Dizem que a versão em Português é ruim, tente a original

Eu acho que os DAO para serem bem aproveitados devem ser totalmente type-safe, ou seja, DAO com intrefaces genericas somente internamente para automatizar operações, mas a interface externa deve ser toda tipada, sem queries genericas.

Mas em contra-partida eu acho que ele deve ser o mais generico possivel em relacao a suas operacoes.
Acho que o desafio dos DAO é tentar representar as funcionalidades da SQL na linguagem OO aproveitando os recursos type-safe.
Agora colocar métodos relacionados com regras de negócio com DAO é muito estranho.
Já vi exemplos de DAO com métodos gerarFatura, registrarVenda.
Para mim são métodos de lógica de negócio não lógica de dados.

Um modo de interesante de ver os dados é ve-los como repositório de dados, ou melhor, repositório de objetos. Alias já vi autores que preferem esta denominação (Repositorio).

Como vocês geralmente implementam isto ?
A separação da lógica de dados da lógica de negócios.

Gostaria da opinião de vocês.

Eu acho que DAOs são tediosos e não são nenhum desafio.

Costumo agrupar os daos por use cases e entidades, dai é só colocar os métodos que atendam os cenarios que surgir.

jprogrammer, sem lazy loading e com métodos genéricos, você vai ter alguns problemas em aplicações grandes.

Por exemplo, imagina que eu tenho um método

public Usuario buscar(int id)

Que faz o que aprece fazer, traz objetos da base de dados.

Agora imagina que você precisa de uma lista de usuários para o administrador. Se você usar esse me´todo genérico, vai ter que chamá-lo várias vezes. Se o método retornar uma lsita de usuários, você vai ter que retornar toda a lista e filtrar o resultado baseado nos parâmetros que o administrador passar.

Isso pode ser resolvido com um método especializado em recuperar objetos segundo um critério X.

Imagine que o adminsitrador vai poder ver uma ficha resumida dos usuários. Se seu método genérico trouxer todo o grafo de objetos, você vai ter centenas de objetos inúteis em memória.

Se seu método genérico não trouxer os relacionamentos, você vai rpecisar de algo do tipo:

Usuario a = daoUsuarios.buscar(codigo);
GrupodeUsuarios g = daoGrupos.buscar(a.getCodigoGrupo());
...

E acabar piorando.

Sem lazy-loading, fica difícil trabalhar com relacionamentos de maneira genérica.

DAOs devem ser usados em aplicações simples, para casos complexos, tente um framework de verdade, onde você não rpecisa se preocupar com a profundidade ou inutilidade do seu grafo de objetos.

Quanto aos métodos “de negócio”, acredito que esses DAOs citados não estão no que falei sobre métodos específicos. Métodos de pesquisa especializados e não genéricos não processam nada (até podem, por conveniência, mas sem abusos), eles apenas fazem pesquisas no SGBD de acordo com um processo específico.

Estamos lidando com a limitação do modelo relacional e principalmente com o impedance mismatch aqui, não encotnrei até hoje uma solução simples para relacionamentos complexos passados para um SGBD que não envolvesse frameworks, métodos especializados em um DAO, código chamando DAOs o tempo todo ou implementações grosseiras de proxies

Se tiver que usar DAO com SQL puro, uso métodos especializados. Se o seu número de objetos for muito simples, você pode se virar com DAOs CRUD, mas quando você tem coisas muito complexas, não vai adiantar muito…

Não seria melhor ver os aobjetos de maneira agrupada do que ver uma relacionamento de objetos em uma consulta especifica.
ex:

class Funcionario
{
    private int codigo;
    private String nome;
    private Departamento departemento;
    // getter and setters
}

class Departamento
{
    private int codigo;
    private String nome;
}

// para deixa type-safe
// no 1.5 pode ser generics
// lazy load numa boa
class FuncionarioColecao
{
    public Funcionario getFuncionario() {}
}

class FuncionarioDAO
{
    public FuncionarioColecao consultar()
    {
       // retorna funcionarios;
    }    
}

FuncionarioColecao funcionarios = FuncionarioDAO.consultar();
while (funcionarios.proximo())
{
    Funcionario funcionario = funcionarios.getFuncionario();
 
   imprima(funcionario.getDepartamento().getNome());
}

Você não precisa de um relacionamento explicito.
Voce parte do prncipio que está fazendo uma consulta de funcionarios, departamento esta agregado.
Então a consulta parte do FuncionarioDAO.
Agora internamente podema usar o framework.

jprogrammer:

Não seria melhor ver os aobjetos de maneira agrupada do que ver uma relacionamento de objetos em uma consulta especifica.

Você não precisa de um relacionamento explicito.
Voce parte do prncipio que está fazendo uma consulta de funcionarios, departamento esta agregado.
Então a consulta parte do FuncionarioDAO.
Agora internamente podema usar o framework.

Duas coisas aí.

Primeiro, sem lazy-loading, você pdoe ter problemas em trazer a estrutura, como eu já disse.

Imagina um banco coorporativo grande, onde um usuário tem um perfil, um grupo, dezenas de operações…tudo registrado.

Se eu trouxer a árvore toda, vou ter vários OutOfMemory e um sistema muito lento sem necessidade. Se eu trouxer aos poucos sem lazy-loading vou ter várias chamadas a DAOs diversos o tempo todo, se eu usar lazy-loading, posso usar um framework

Note que estamso falando em DAOs que acessam um banco de dados direamtnente, não um DAo para Hibernate, por exemplo.

Mas posso ter a arvore de objetos somente como estrutura e instanciar somente os campos que preciso.
Tem algum problema.

class Funcionario
 {
     private int codigo;
     private String nome;
     private Departamento departemento = null;
     // getter and setters
 }
 
 class Departamento
 {
     private int codigo;
     private String nome;
 }
 
 // para deixa type-safe
 // no 1.5 pode ser generics
 // lazy load numa boa
 class FuncionarioColecao
 {
     ResultSet result;
    boolean retornaDepartamento;

     FuncionarioColecao(ResultSet result,boolean retornaDepartamento)
     {
         this.result = result;
         this.retornaDepartamento = retornaDepartamento
;
     }

     public boolean proximo()
     {
          return result.next();
     }

     public Funcionario getFuncionario()
     {
          funcionario = new Funcionario();
          funcionario.setCodigo(rs.getLong("CODIGO"));
          funcionario.setNome(rs.getLong("NOME"));
          if (retornaDepartamento)
          {
             departamento = new Departamento();
             departamento.setNome(rs.getString("DESC_DEPARTAMENTO"))
             funcionario.setDepartamento(departamento);
          } 

          return funcionario;
     }
 }
 
 class FuncionarioDAO
 {
     public FuncionarioColecao consultar(boolean retornarDepartamento)
     {
         if (retornarDepartamento)
          // faco join com departamento

         return new  FuncionarioColecao(result,retornarDepartamento);

     }    
 }
 
 FuncionarioColecao funcionarios = FuncionarioDAO.consultar(true);
 while (funcionarios.proximo())
 {
     Funcionario funcionario = funcionarios.getFuncionario();
  
    imprima(funcionario.getDepartamento().getNome());
 }

Acoplamento.

Para estruturas simples, pdoe ser bem prático. Para grafos complicados (Usuário tem um perfil, pertence à um Grupo, á numa Rede, pode se comunicar com n outros Usuários…) você vai ter mais variáveis de controle do que or estante do código no sistema

Mas quando se tem uma variável do tipo de uma classe determinada, mas ela não tem referencia isso não afetaria a performance ?
Ou afetaria ?
ex:

Departamento dep = null; // não tem instancia, só se eu precisar;

Mas em uma estrutrura altamente “cascateada” como você falou, tirando incomodo de ter variaveis de controle, o existiria o problema de performance ?

Já fiz uma teste serializando uma classe.
E só por ela ter variavel sem instancia (null) o tamanho dos bytes aumentaram.
Agora não sei se meu tipo de medição tem alguma coerencia.

Teoricamente, sua medição não tem muito sentido, creio. Objetos em memória e Serializados possuem diferenças.

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.

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:

class FuncionariosRegras
{
   public void cadastrar(Funcionario funcionario)
   {
       if (funcionario.getCodigo() == 0)
         throw new BusinessException("Código com valor inválido");

      // demais validacoes e verificacoes

     FuncionarioDAO.inserir(funconario) // faz persistencia
   }
}

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.

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.

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:

void cadastraViaWeb() {
  Funcionario f =  new Funcionario();
  ....
  f.save(); //valida se pode ser salvo e chama o dado para "dar o insert"
}

void migraCadastroDeSistemaAntigo() {
  Functionario f =  new Funcionario();
  ....

  f.save(); //valida se pode ser salvo e chama o dado para "dar o insert"
}

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

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).

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 :roll: ?

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

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:

// esta no singular
class Funcionario
{
   private int salario;

    public void promover()
    {
     // faco validacoes

       salario += 800.00;
       // depois eu persisto
    }

}

// esta no plural
class Funcionarios
{
   public void promover(int codigoDepartamento)
   {
     // faco validacoes

      FuncionarioDAO.atualizarSalarios(codigoDepartamento,800.00);
   }
}

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).

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.

FuncionariosDoDepartamento f = new FuncionariosDoDepartamento("TI");
f.mandaPraRua();

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:

class Apontamentos
{
   public void processarApontamento(int diaIni,  init diaFim)
   {
       // preciso pegar uma colecao de funcionarios, pois o processo é complexo e só update nao serve
      
     // faco iteracao pela colecao e faço apontamento para cada funcionario
   
   }
}

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

class Funcionario
{
   public void tranferirdeFilial()
   {
      // é um metodo muito complexo 
    }
}

É 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.

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:

class Funcionario
{
   private int horarioSaida;

   public int calcularHoraExtra(int dia)
   {
      // busca a marcacao do funcionario no dia;

       Marcacao marcacao = MarcacaoDAO.consultar(dia,this.getCodigo());
       if (marcacao.getMarcacaoDaSaida() > horarioSaida)
          return marcacao.getMarcacaoDaSaida() - horarioSaida;
   }
}