Padrão DAO e MVC

Assuntos Gerais
#1

Bom, estou habituado a utilizar o Padrão DAO em meus projetos, li sobre o padrão MVC e notei que não há muita diferença do padrão DAO. Vou fazer uma analogia do padrão DAO com o MVC e peço que me falem se estiver errado.

  • Classe POJO/DTO no DAO Corresponde ao Model no MVC.
  • Classe DAO tanto no MVC como no padrão DAO continua sendo DAO mesmo :slight_smile:
  • E no MVC temos a inserção do Controller que captura os dados do View.

Vamos ao exemplo prático em um cadastro de Clientes:

Camada MODEL ou POJO/DTO

  public Class ModelCliente{
    private int codigo;
    private String nome;

    public int setCodigo(int codigo)...
    public int getCodigo()...

   public String setNome(String nome)...
   public String getNome()...
  }

Camada DAO

  public Class DaoCliente{

      public boolean inserir..
      public boolean deletar...
      public boolean editar...
      ...    
  }

Camada CONTROLLER (APENAS PRESENTE NO MODELO MVC)

  public Class ControllerCliente{
     public boolean InserirCliente(){
         mCliente = new ModelCliente();
         mCliente.setCodigo(1);
         mCliente.setNome('Ronaldo');
         
         daoCliente = new DaoCliente();
         daoCliente.inserir(mCliente);
    }
        ....
  }

E finalmente a camada VIEW que depende de onde você está desenvolvendo, Ex:
Delphi = FORM
JAVA = pagina html, jsp …
PHP = pagina php, html …
e por ae vai.

Está certo ?

#2

Assim o DAO seria a camada de Model do MVC (Model-View-Controller)

Se tiver um tempo da uma olhada na apostila FJ-21 da Caelum muito boa e
a respeito do MVC esta muito bem explicado…

Sempre recomendo uma boa olhada nessa apostila

#3

Certo, sabendo que o DAO = MODEL, o Controller está correto como coloquei acima ?

#4

Cara, não acesse seu DAO na camada de Controller e ainda mais, por uma classe concreta (use interfaces), isso gera acoplamento fortíssimo.

Geralmente uma boa arquitetura básica, tem no mínimo Controller (Classe controladora) -> Model (Regras de negocio (aqui você acessa seu DAO para manter/buscar dados)) -> DAO.

#5

Cara, não acesse seu DAO na camada de Controller e ainda mais, por uma classe concreta (use interfaces), isso gera acoplamento fortíssimo.

Geralmente uma boa arquitetura básica, tem no mínimo Controller (Classe controladora) -> Model (Regras de negocio (aqui você acessa seu DAO para manter/buscar dados)) -> DAO.

#6

Como ficaria usando interfaces ?

#7

Esse exemplo de DAO seria uma interface

public class Contato {}

public interface ContatoDAO {
void inserir(Contato contato);
void alterar(Contato contato);
void exluir(int id);
Contato buscar(int id);
List<Contato> lista();
}

import java.util.List;

public class ContatoMySqlDAO implements ContatoDAO{

public void inserir(Contato contato) {
	// codigo
	
}

public void alterar(Contato contato) {
	// codigo
}

public void exluir(int id) {
	// codigo
}

public Contato buscar(int id) {
	// codigo
	return null;
}

public List&lt;Contato&gt; lista() {
	// codigo
	return null;
}

}

Assim vc utiliza sempre referenciando um ContatoDAO, ganho no polimorfismo

#8

Certo , entendo o uso de interfaces com DAO, mais não vejo ganho nisto, sei o que é polimorfismo mais ainda não consigo enxergar um ganho. Poderia dar um exemplo ?

#9

Seu Controller esta correto, entendi o que vc pergunto, ele faz o papel de Controller, o alto acoplamento seria com o DAO utilizando daquela maneira seria legal num cenario onde vc trabalha com mais BD, ou seu sistema tem a tendencia a mudança de banco ou surgimento de novos

#10

em qualquer mudança no cenario, vc estaria utilizando no Controller
ContatoDAO contatoDao =
new ContatoMySqlDAO();
new ContatoOracelDAO();
new ContatoSQLDAO();
um exemplo meio tosco mais exemplificando o que falei.

#11

Ta mais daria no mesmo se fizesse:

ContatoMySqlDAO c1 = new ContatoMySqlDAO(); 
ContatoOracelDao c2 = new ContatoOracelDAO(); 
ContatoSQLDao c3 = new ContatoSQLDAO();
#12

Só uma coisa, não é porque você nomeia uma classe como DAO (ContatoDAO, ClienteDAO, UserDAO), que ela é um padrão DAO. O DAO é um padrão e para você implementar esse padrão deve seguir as especificações do padrão.

E a primeira coisa a fazer é uma interface DAO e implementar essa interface na(s) sua(s) classe(s) especifica(s) de DAO. Você pode ter uma interface DAO para cada classe concreta, tipo: IUserDAO, UserDAO. Ou pode ter uma única interface DAO que implemente todas as demais classes especificas ou um classe genérica de DAO que será expendida em seus DAOs específicos.

[quote]Certo , entendo o uso de interfaces com DAO, mais não vejo ganho nisto, sei o que é polimorfismo mais ainda não consigo enxergar um ganho. Poderia dar um exemplo ?[/quote] Se não usar, não terá um padrão DAO, terá apenas um pacote e uma classe chamada DAO.

#13

Então eu devo fazer:

IModeloDAO {
inserir
editar
deletar
buscarPorID
}

DaoCliente implements IModeloDAO{
inserir{…}
editar{…}
deletar{…}
buscarPorID{…}
}

#14

Esse exemplo meu ficou tosco,
Mais vale a pena pensar que utilizar de forma mais Generica acaba sendo um ganho, principalmente em mudanças de cenario.

O padrão Data Access Object (DAO) é simplificar e desacoplar a interação das aplicações Java com a base de persistencia.

Então o ganho do uso de interface é o desacoplamento, num cenario onde o surgimento de novos BD ou a troca da BD é normal ou possa acontecer,
ter um sistema onde vc tem uma mudança sem ter que mudar muito é otimo
Mais vc poderia ter sua Classe DAOCliente sem ter uma interface, seria seu DAO.
Pense se pode mudar é bom se preparar, deixar preparado para mudanças.

#15

Pois é leulseixas, como havia dito entendi o funcionamento porém ainda não vi necessidade em utilizar Interfaces.

1 curtida
#16

[quote=rlanhellas]Então eu devo fazer:

IModeloDAO {
inserir
editar
deletar
buscarPorID
}

DaoCliente implements IModeloDAO{
inserir{…}
editar{…}
deletar{…}
buscarPorID{…}
}
[/quote]

Seria por esse caminho mesmo.
Ou você pode fazer um IDAO

   IDAO {
      inserir
      editar
      deletar
      buscarPorID
   }

E implementa-lo em qualquer classe de DAO especifico, te poupa um pouco de trabalho.

E ainda pode fazer isso

   IDAO {
      inserir
      editar
      deletar
      buscarPorID
   }

   abstract DAO<T> implements IDAO {
      //aqui você cria a implementação dos métodos da interface
   }

E depois nas classes especificas você estende a classe abstrada e já terá acesso ao métodos implementados em qualquer classe de DAO especifico que estender DAO. E nas classes especificas de DAO, dai você pode criar qualquer método de CRUD que seja mais especifico para cada classe.

Lembre que se você implementar o padrão MVC sem o Controller, ele não será um MVC. A mesma coisa vale para o DAO, se implementar sem interface ele não será um padrão DAO apenas você terá uma classe de persistência sendo chamada de DAO.

#17

Me diga uma coisa, a camada VIEW pode se comunicar com a MODEL ?

#18

Não, isso quem faz é o controller. Mas por exemplo, se for uma app desktop, você pode acabar precisando ter um objeto da sua entidade na view, mas se limitaria a isso, regras de negócio só devem ser acessadas pelo controller.

#19

Então qualquer regra de negócio será sempre aplicada na camada CONTROLLER?

#20

Toda a regra de negócio vai na camada do Model, não do Controller. O Controller apenas recebe as requisições da View e delega para o modelo processar. Por exemplo se na sua View o usuário clicar no botão de finalizar pedido, seu controller pegara por exemplo o Objeto carrinho do modelo e ira chamar um metodo como carrinho.realizarPedido() e ai dentro estara suas regras.

Quanto a usar interface para Dao é interessante para testes unitários onde você normalmente precisara mockar elas.