DAO encapsulado no Domínio/Modelo

Programação Arquitetura
#1

Bom dia!!

Eu to tentando implementar o padrão DAO e to com dúvida onde usar os métodos.
Por exemplo, na minha camada de Controle como eu deveria implementar:

Busca de clientes:

ClienteDAO cliente = Factory.createClienteDAO;
List cliente  = cliente.findAll();

ou

List clientes = Cliente.getClientes();
//getClientes() é o método estático que encapsula o cliente.findAll();
#2

[quote=carrijo]Bom dia!!

Eu to tentando implementar o padrão DAO e to com dúvida onde usar os métodos.
Por exemplo, na minha camada de Controle como eu deveria implementar:

Busca de clientes:

ClienteDAO cliente = Factory.createClienteDAO;
List cliente  = cliente.findAll();

ou

List clientes = Cliente.getClientes(); //getClientes() é o método estático que encapsula o cliente.findAll(); [/quote]

Se existe um objeto que é responsável por fazer pesquisas esse não é o proprio objeto pesquisado, logo a primeira opção é melhor.
Contudo vc pdoeria melhorar isso usando um Registro. A fabrica serve para criar, não para encontrar. Ficaria asssim

RepositorioCliente repositorio = Repositorios.doCliente();
List<Cliente> clientes = repositorio.findAll();

//ou 

List<Cliente> clientes =  Repositorios.doCliente().findAll();

dentro d Repositorios…

[code]
class Repositorios{

static Map<String, Repositorio > repositorios = TreeMap<String, Repositorio>();

static {

repositorios.put(“cliente” , Factory.createClienteRepository());

}
public static RepositorioCliente doCliente (){
return repositorios.get(“cliente”);
}

}[/code]

Vc pode levar as coisas mais longe :


List<Cliente> clientes =  Repositorio.de(Cliente.class).findAll();

// e 

abstract class Repositorio<E>{

static Map<String, Repositorio > repositorios = TreeMap<String, Repositorio>();

static {

  repositorios.put(Cliente.class.getName() , Factory.createClienteRepository());

}
public static <T> Repositorio<T> de<Class<T> entity){
      return repositorios.get(enity.getName());
}

}

(Nota : um objeto onde se fazem pesquisas de negocio é um Repositorio , não um DAO.)

#3

Blz acho q entendi!

Mas to achando estranho o fato de estar implementando a msm coisa, soh q mudando o nome de DAO para Repositorio.
Tipo, onde entra o DAO nesse modelo?

#4

sergiotaborda disse tudo.

o seu DAO vai ficar atras do Repositorio. isso evita que seu modelo de dominio seja poluido/acoplado com um DAO especifico…

#5

[quote=carrijo]Blz acho q entendi!

Mas to achando estranho o fato de estar implementando a msm coisa, soh q mudando o nome de DAO para Repositorio.
Tipo, onde entra o DAO nesse modelo?[/quote]

Com sorte, o DAO não entra nesse modelo :wink:
Hoje em dia construir DAOs é uma perda de tempo no caso geral. DAOs, hoje em dia, são apenas bons no caso de sistemas legados
já que eles fazem o papel de “tradutor” entre o legado e a aplicação.
Vc vai, atualmente, usar um Hibernate ou um JPA ( um DomainStore em geral). Ou seja, vc vai usar outra biblioteca que é mais que um DAO. Claro que vc pode criar o seu próprio DomainStore, mas isso não é aconselhado para cardíacos…

Moral da historia :

  1. preocupe-se com os repositórios primeiro. O que está abaixo deles é mecânico, é coisas chata, aborrecida e automatizada por API modernas.
  2. Use implementações de DomainStore e não de DAO.
#6

camadas e mais camadas…até onde iremos…

entre seu DAO e seu CONTROLE não existe mais nada portanto vc só pode usar uma instancia do DAO.

Ou então fazer como os colegas acima disseram q criar mais uma camada…tomara q não venha ninguém pedir pra vc criar um facade pro repositório…

#7

?A maior parte dos problemas em Ciência da Computação pode ser resolvida por um nível adicional de indireção? 8)

#8

Ahauahauahuaau! Q doidera!

Mas blz, acho q compreendi!
Vlw msm, td mundo ae!

#9