Implementando DAO

Ola galera!

Td joia com vcs?!

Galera, estou aprendendo Padrões de Projeto…rsrss…e estou no que mais da discução “DAO”. Eu entendi o macete que o DAO traz, é muito facil para dar manutenção. Mais eu so vejo exemplos pequenos dele.

Como eu faço para usar o padrão DAO na hora de usar 2, 3, 4 Tabelas e uma relacionada com o outro?

Como eu faço as minhas busca quando tem relacionamento?

o DAO é legal na teoria, mais com os exemplos que eu vi to vendo que na pratica é dificil o uso dele.

Olá rickab7,

Eu venho estudando também esse esquema show de DAOs e posso te garantir que um bom sistema precisa deles. é uma boa cultura.

Tem alguns posts meus que tento tirar dúvidas sobre DAO, você pode dar uma olhada que o pessoal aqui foi bem bacana e me ajudou muito.

http://www.guj.com.br/posts/preList/66337/349557.java

http://www.guj.com.br/posts/preList/66337/349364.java

http://www.guj.com.br/posts/preList/66036/348247.java

E tem um monte de outros tópicos que falam sobre o bendito.

DAO GUJ

Dá uma olhada, se tiver ainda duvidas, manda aí :slight_smile:

sds

[quote=rickab7]Ola galera!

Td joia com vcs?!

Galera, estou aprendendo Padrões de Projeto…rsrss…e estou no que mais da discução “DAO”. Eu entendi o macete que o DAO traz, é muito facil para dar manutenção. Mais eu so vejo exemplos pequenos dele.

Como eu faço para usar o padrão DAO na hora de usar 2, 3, 4 Tabelas e uma relacionada com o outro?

Como eu faço as minhas busca quando tem relacionamento?

o DAO é legal na teoria, mais com os exemplos que eu vi to vendo que na pratica é dificil o uso dele.[/quote]

O objectivo do DAO (Data Access Object - Objcto de Aceso a Dados) é isolar a camada superior do acesso aos dados. Ele segue o conceito de “diz-me o que queres que te traga e não como queres que procure”.
O DAO é como um garçon bem treinado.
Portanto o que vc tem que pensar é que um DAO pode fazer qq coisa por você e você não pode se preocupar com o como. Por isso um DAO é definido em duas partes. Uma interface e uma implementação.
A interface é o DAO - não se engane pensando que a implementação é o DAO, não - ela define o que vc precisa obter. Vc cria métodos como
"traz-me todos os clientes com compras feitas acima de 300000 reais"
ou "traz-me todos os produtos fora de linha"
Repare que a granulidade destas pesquisa é bem grande. Para as executar vc terá que escrever SQL mais ou menos complexo e tlv mais do que uma frase SQL. Não importa. O DAO não se preocupa com isso.
Se vc cria um DAO com granulidade fina como “traz-me todos os X que correspondam com o critério Y” vc não está fazendo um DAO e sim um intrepretador de queries. Mas tudo bem, isso é apenas um DAO com granulidade muito fina.
Independentemente da granulidade alguem tem que fazer o trabalho de trazer as coisas. Esse trabelho é da implementação do DAO.
A implementação sabe onde os dados estão e como procurar por eles.
Ela é livre de fazer qq coisa em ordem a cumprir o acordo ( a interface)
Portanto se a sua pesquisa usa 20 tabelas a implementação usara 20 tabelas. Ou seja, vc vai codificar tudo bonitinho usando SQL e JDBC e as 20 tabelas.

Claro, ninguem quer usar JDBC desta forma. Então provavelmente vc usará uma ferrramenta ORM (Que é um DAO de granuliade muito fina , aka generico de mais, que pode exeuctar via OO coisas que vc executaria via SQL ) para fazer esse tabalho real (e sujo) de procurar as coisas. Mas em certos casos o JDBC pode ser uma muito melhor alternativa caso , por exemplo, a pesquisa seja muito complexa, ou precise ser muito otimizada ou muito especifica do Banco que Vc está usado.

Enfim, todo o mundo quer na realidade uma ferramenta ORM e o DAO de alta granulidade é uma camada acima dessa onde são escritas pesquisas macro, que realmente têm muito a ver com o negocio e pouco com as tabelas. Um sistema pode ter mais do que um DAO conforme as granularidades das suas pesquisas, mas as pessoas gostam de ter apenas o de granulidade fina (aka ORM) e escrever as pesquisas contra ele.
No geral funciona, mas em particular pode não ser a solução definitiva.

A ideia de implementação do DAO é a mesma de um DTO? :?:

Da pra coloca um DAO dentro de um DTO neh? :?:

Obrigado… :wink:

Não. Um DTO (Data Transfer Object - Objecto de Transferencia de Dados) não é nem de perto o mesmo que um DAO (Data Acesso Object - Object de Acesso a Dados)

O DAO é um objecto que acessa o banco e le dele as informações.
Um DTO, tb conhecido como TO, é um objecto que é transferido entre um nodos das aplicação (máquinas em que aplicação corre). O DTO contém os proprios dados e sua serialização é especial de forma a pesar pouco na rede.

Um DAO normalmente usa objectos para responder às pesquisas.
Por exemplo, “DAO, traz todos os clientes que fazem anos amanha” vai trazer uma coleção de clientes ou seja um Collection
Client é uma classe de objetos que contém dados do cliente. Este objecto corresponde ao padrão Entity. Ele tb é serializável como o DTO, mas não tem uma serialização especial (logo não é um DTO)

O normal é um DAO retornar Entity ou coleções de Entity (1). Pode também (2) retornar DTO ou coleções de DTO. Mas um DTO que faça (1) não deve fazer (2). Entenda, a granulidade de um DTO é maior que a de um Entity.

Não.

A minha primera pergunta foi mal formulada… apesar disso, sua explição não foi em vão… xD

A ideia de implementação q eu digo… eh se o DTO assim como o DAO tb usa classes Interfaces??

e uma duvida basica… se qdo vc usa algum metodo que ta na interface, vc acessa a interface ou a classe que implementa ela…

vlws!

Galera, valeu pela Dica.

Estou tentando implementar um DAO…so assim para entender bem.

Mais não sei pq esta dando erro no meu codigo.

A primeira Classe é que faz conexão com o banco e a segunda e a interface

package br.com.teste.dao;

import java.sql.*;
import javax.swing.JOptionPane;

public class DAO{
 
	private String url;
	 
	private String driver;
	 
	private String login;
	 
	private String senha;
	 
	private Connection con = null;
	 
	private Statement st;
	 
	public Connection Conecta() {
		
		url = "jdbc:odbc:consultorio";
		driver = "sun.jdbc.odbc.JdbcOdbcDriver";
		
		try
  		{
  			Class.forName(driver);
      		con = DriverManager.getConnection(url);
      		
      		
      		
  		}catch(Exception ex){
    			JOptionPane.showMessageDialog(null, "Conecção aceita" + ex);
    	}
    	
    	return con;
	}
	 
}
 
package br.com.teste.dao;

import java.util.List;
import br.com.teste.dao.DAO;

public interface iDAO<Entidade> extends DAO{
 
	public abstract boolean Save(Entidade entidade);
	public abstract boolean Delete(Entidade entidade);
	public abstract boolean Update(Entidade entidade);
	public abstract Entidade Select(Entidade entidade);
	public abstract List SelectAll(Entidade entidade);
}
 

Qual o erro que ocorre?

Olá
O erro no seu código é porque você está herdando um a classe concreta em uma interface. Interfaces só podem herdar interfaces.

flw.

[quote=lsr]A minha primera pergunta foi mal formulada… apesar disso, sua explição não foi em vão… xD

A ideia de implementação q eu digo… eh se o DTO assim como o DAO tb usa classes Interfaces??
[/quote]

Normalmente não, isto porque um DTO tem que ter uma serealização especial que é feita com métodos privados e portanto cada DTO é um DTO.
Claro que o DTO pode implementar interfaces do seu sistema, mas elas nada têm a haver com DTO em si.

A classe que a implementa.

vlw… sergiotaborda
num tenho mais porguntas… por agora… xD

vlw

Eae galera salve, meu DAO ta inserindo mas não ta atualizando,não da nenhum erro, se alguem souber onde estou errando, quem vê de fora enxerga melhor, as classes são essas:

public void atualizar(Produto produto) throws SQLException{
         conectar();
         String com = " UPDATE produto Set nome = '" + produto.getNome()
                 + "', descricao ='" + produto.getDescricao() + "', preco = "
                 + produto.getPreco() + " WHERE codProduto= " + produto.getCodProduto()+";";
         System.out.println("Atualizada");
         try{
             comando.executeUpdate(com);
         }catch (SQLException e) {
             e.printStackTrace();
         }finally{
             fechar();
         }
     }
private void jButtonatualizaActionPerformed(java.awt.event.ActionEvent evt) {                                                
          Produto produto = new Produto();
          DaoProduto daoProduto = new DaoProduto();
       produto.setCodProduto(Integer.parseInt(jTextFieldcodigoproduto.getText()));
            produto.setNome(jTextFieldproduto.getText());
            produto.setDescricao(jTextFielddescricao.getText());
            produto.setPreco((float) Double.parseDouble(jTextFielpreco.getText()));
        try {
            daoProduto.atualizar(produto);
        } catch (SQLException ex) {
            Logger.getLogger(NewJFrameCadastroProduto.class.getName()).log(Level.SEVERE, null, ex);
        }
       
         
    }     

desde ja grato pela atenção galera ate

então cara vc ta on ? não entendi a brincadeira mas valeu pelo card

A questão é que você postou algo que não tem nada a ver com o tópico(discussão arquitetural e teoria), no fórum errado, 3 anos e meio depois que o tópico encerrou a discussão. É a coisa mais “Joselito” de se fazer aqui no GUJ.

Coloque a tua dúvida no fórum de Java Avançado, se quiser alguma resposta.

Bom, aproveitando que já reviveram o tópico com a carta mágica…

Imaginem uma tela de consulta onde o usuário pode combinar algumas condições disponíveis e montar um filtro: Ex: Consultar clientes ativos na cidade X

Essa consulta deve ser passada para um DAO? E como lidar com esse filtro dinamico?

[quote=magnomp]Bom, aproveitando que já reviveram o tópico com a carta mágica…

Imaginem uma tela de consulta onde o usuário pode combinar algumas condições disponíveis e montar um filtro: Ex: Consultar clientes ativos na cidade X

Essa consulta deve ser passada para um DAO? E como lidar com esse filtro dinamico?[/quote]
Acredito que sim.
Existiria um DAO de um nível mais elevado, com um método mais inteligente de elaboração da query de consulta. Ou seja lá onde el for consultar os dados, afinal isso deve ser transparente a quem o usa.
Pense bem, se não passar por um DAO quem o fará? A própria view montara a query e fará a consulta JDBC? A view montará a query e enviará pro model?
Nenhuma dessas últimas alternativas me parecem interessantes. Eu não o faria dessa forma.

Lógico que dependendo do nível de dinamismo que você quiser a complexidade do DAO aumentará e pode exigir uma arquitetura mais avançada, robusta. Mas isso deve ficar transparente a quem o chama, ficando de conhecimento comum apenas o contrato.

Abraços!

Foi mal não imaginei que vcs não manjassem de codigo mas so de arquitetura e teoria,mas relaxa vou ver se eu compilo um exemplo mais simples que eu tenho aqui funcionando vou debugar o exemplo questão pra ver se eu encontro o erro,é que geralmente eu coloco o erro ou o topico em questão no google e cai no topico certo do forum,e as vezes sa correia é tão grande que a gente sai igual um louco pra tentar resolver e acaba ate ficando cego.mas de boas vlw galera pode continuar a discussão ai abraço

Não foi isso que ele quis dizer.

É que você tentou sequestrar um tópico, ou seja, pegou um tópico num assunto e começou a fazer outras perguntas.
O mais recomendado é que se abra um tópico novo citando (com um link) o tópico que julgou importante, compreende?

É que se ficarem vários assuntos distintos discutidos no mesmo tópico (e esse não for off-topic) fica difícil pesquisar depois.

Abraços.