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<Contato> 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

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.

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 ?

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.

rlanhellas:

Então eu devo fazer:

IModeloDAO {

inserir

editar

deletar

buscarPorID

}

DaoCliente implements IModeloDAO{

inserir{…}

editar{…}

deletar{…}

buscarPorID{…}

}

</blockquote>

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?

Isso pode ser ate uma validação do seu POJO, basta vc saber onde esta fazendo, na VIEW via JavaScript, no CONTROLLER quando vc recebe os parametros, acho que o menos recomendado seria no MODEL ante da inserção mais não sei se implica algo ficaria
Trate isso na camada que mais visivel fica normalmente eu trataria isso no Controller posso estar errado mais acho que isso vai de acordo com seu objetivo.Que de fato seria separar bem cada camada.

.

O padrão DAO e o padrão MVC tem fins completamente distintos. O objetivo do DAO (Data Access Object) é abstrair o acesso ao mecanismo de persistência, seja ele uma base de dados, um arquivo de texto ou alguma interação com web services. Utilizando DAO você poderia alterar esse mecanismo de persistência sem impactar no restante da sua aplicação.

O padrão MVC, por outro lado, define um modelo de interação entre Model, View e Controller. Estes componentes podem ou não estar em camadas separadas. Veja:

http://fragmental.com.br/wiki/index.php/MVC_e_Camadas.html

No MVC tradicional o Controller interage com o Model, que notifica a View quando seu estado é alterado (usando o padrão Observer, por exemplo). Há também o que se chama de MVC 2, onde o invés de o Model notificar a View, é o Controller que faz este trabalho (mais comum em aplicações Web).

Se você analisar um framework MVC, como o spring MVC a separação fica clara. Você tem um controller que recebe requisições do usuário. Este controller interage com o Modelo e retorna para a View o novo estado. Se o modelo acessa diretamente o DAO, ou acessa um repositório, ou acessa um serviço, isso não diz respeito ao MVC, afinal de contas o MVC nem sabe o que é isso. =D