Se usamos o padrão DAO para encapsular todo acesso ao banco de dados não deveríamos criar/obter um conexão dentro de uma classe DAO? Nos exemplos, a conexão com o banco de dados sempre é repassada para uma DAO através do seu construtor. Esse é o padrão correto?
try (Connection con = new ConnectionPool().getConnection()) { ProdutosDAO dao = new ProdutosDAO(con); dao.salva(mesa); }
hoje, com a Alura e o Google Gemini
Olá!
Existem 2 grandes motivos para isto, vou tentar explicar:
1) A conexão deve ser passada por uma questão de performance e reuso de objetos. É muito custoso/demorado abrirmos uma nova conexão a cada iteração que fizermos no banco de dados. Imagine que cada vez que você cria a conexão, sua classe Java precisa se comunicar com a JVM através do Driver do banco de dados, a JVM por sua vez conversa com o Sistema Operacional, o Sistema Operacional conversa com a rede (caso o banco de dados não esteja na mesma maquina por exemplo) e assim sucessivamente.
Além disto também é necessário todo o processo de autenticação no banco de dados a cada nova abertura de conexão, quando você passa a conexão pronta para o DAO, tudo isto já está pronto.
Quando criamos uma conexão antecipadamente, já deixamos tudo pronto para nossa DAO poder utilizar e economizamos muito tempo com o "reuso" deste objeto (neste caso, o objeto conexão).
2) O segundo beneficio é que, você pode utilizar uma mesma conexão com vários DAOs, imagine que você precise atualizar 2 ou mais tabelas ao mesmo tempo, porem se ocorrer um erro, você precisa desfazer todas as alterações (rollback). Quando você passa a conexão para o DAO, ele deixa de ser o "unico" dono deste objeto e passa a compartilhar a conexão entre varios DAOs, permitendo assim que você consiga executar um commit ou rollback em toda a transação do banco de dados.
Espero ter conseguido explicar bem! Bons estudos! Um abraço!
Olá, Diogo! Obrigado por participar. Foi uma boa explicação.
Só achei estranho outra camada repassar a conexão para a DAO. Mas depois da sua explicação entendi esse motivo.
Então se falarmos a nível de frameworks, teríamos, por exemplo, uma conexão gerenciada pelo Spring que sempre estará pronta para quem precisar usar, é isso?
Por exemplo: ao usar um EntityManager, esse já terá uma conexão pronta e então não preciso me preocupar com a infra para gerenciar essa conexão.
Positivo!
Você entendeu perfeitamente!
Na pratica você perceberá que o 2º beneficio chega a ser "maior" que o primeiro, pois o controle sobre uma transação do Banco de Dados é feito através da conexão (ainda que uma conexão possa possuir varias transações), ou seja, você só consegue ter commit e rollback com a mesma conexão (nativamente).
Exemplo:
Você possui uma tabela para "Pedidos" e uma outra tabela para "Itens do Pedido", você pega uma conexão, inicia uma transação sobre ela e insere um Pedido, a DaoPedido irá encapsular o insert para você, depois você começa a inserir os itens deste pedido através por exemplo da DaoPedidoItem, e derrepente... um item sofre um erro do banco de dados e não é inserido... com o controle de transação (na mesma conexão), você pode reverter através de um rollback tudo que foi inserido até aquele momento (tanto pela DaoPedido quanto pela DaoPedidoItem) e avisar seu usuario de que o pedido não foi inserido corretamente por estar com um erro no Item "X".
Uma informação adicional é que costumamos chamar esta camada "a mais" de camada de "negócio" (ou business). Quem controla na verdade a inteligencia entre as tabelas (entre as DAOs) é a camada BUS, nela estará praticamente todas as regras de negócio, cabendo a DAO se preocupar apenas com a comunicação com sua própria entidade (tabela).
Espero ter ajudado! Um Abraço e bons estudos!