GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

Padrão DAO e MVC

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

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

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.

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.

Como ficaria usando interfaces ?

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

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 ?

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

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.

Ta mais daria no mesmo se fizesse:

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

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.

Então eu devo fazer:

IModeloDAO {
inserir
editar
deletar
buscarPorID
}

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

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.

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

1 Curtida

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

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

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.

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

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.

No caso eu estou trabalhando com DAO dentro da camada MODEL do MVC. Então se por exemplo eu quiser que todo o nome passado fique maiusculo eu defino na classe DTO (padrão dao) dentro da camada MODEL do MVC?