O pessoal criticar chamar um Repository, ou Dao diretamente da Camada de Apresentação, por exemplo quais são as vantagens de ao inves de fazer:
public class UsuarioAction(){
public void save() {
User use=//popular user com os dados da UI
UsuarioDao dao=new DaoFactory().getUsuarioDao();
dao.save(user);
}
}
public class UsuarioAction(){
public void save() {
User user=//popular user com os dados da UI
UserManager manager=new UserManager(); //Façade
manager.save(user);
}
}
public class UsuarioManager (){
public void save(user){
UsuarioDao dao=new DaoFactory.getUsuarioDao();
dao.save(user);
}
}
IMHO, apenas criei uma “camada” descenecessária que somente delega o metodo, não consigo ver vantagens, nisso, que poderia ser útil ter essa camada?
Eh verdade que em exemplos simples parece ser uma camada desnecessaria, mas mesmo assim veja o item 1) da lista do tnaires. Apesar de que eu mesmo muitas vezes, chamo o repositorio direto da camada de apresentacao quando estou lidando com cruds simples. Se um dia eu precisar usar outra tecnologia de apresentacao, sao apenas cruds e simples de alterar.
Quando é uma regra mais complexa, vale pena por em servicos sim.
Se sua aplicação é simples essa camada a mais é overkill, mas como os colegas disseram, pode servir pra outras coisas. A minha preferência é criar camadas apenas quando eu percebo que está fazendo sentido e não somente porque é bonito ou virou “padrão”.
na prática isso auxiliaria no reaproveitamento das chamadas dos DAOS dentro de uma unica transaction ? uma vez que poderiamos chamar varios managers dentro de uma transaction soh ?
public class UsuarioAction(){
public void save() {
// ABRE TRANSACTION AQUI
User user=//popular user com os dados da UI
UserManager manager=new UserManager(); //Façade
manager.save(user);
// poderia chamar outro manager salvando aqui
// FECHA TRANSACTION AQUI
}
}
public class UsuarioManager (){
public void save(user){
UsuarioDao dao=new DaoFactory.getUsuarioDao();
dao.save(user);
}
}
O seu UsuarioManager tem cara de ser da camada de Business. Camada de aplicação é pouco usado é serve para orquestrar vários componentes de negócio.
Erro 2:
O grande problema do seu exemplo é a falta de abstração, porque, em termos de negócio, não existe inserir, remover, atualizar e selecionar; as pessoas de negócio simplesmente usam outros termos que, muito provavelmente, é a composição de lógica de banco, com algumas validações e cálculos. Exemplo: para um usuário, não existe salvar, existe registrar, trocarSenha, alteraçaoDeCadastro… que seriam métodos de um UsuarioManager (ou UsuarioFaçade, ou UsuarioService, ou UsuarioBusiness, ou …). Esse objeto encapsularia um UsuarioDao (este sim com save) e proveria uma abstração mais alto nível.
Agora, e se você não provê essa abstração de alto nível, e simplesmete, expõe as ações do banco direto pra camada de visualização? Então, o seu UsuarioManager tá ali de gaiato e só serve pra complicar as coisas.
Erro 3:
Não existe CRUD no mundo real. Pensar que tudo é CRUD é consequência de programadores que não sabem analisar o negócio e que forçam o sistema a se adequar numa receitinha de bolo usando excessívas camadas, fraca orientação a objetos e dependência de banco de dados para as validações.
Na prática, sim. Mas o código que você postou está abrindo e fechando transações nas classes de controle - nesse caso, actions. Quem devia estar fazendo isso seria sua camada de aplicação.
[quote=renanreismartins]tnaires valeu por acompanhar a discussao, existem topicos semelhantes mas nenhum foi até o fim da minha duvida.
vc diz que:
ou seja a abertura e fechamento de transacoes deveria estar dentro do UsuarioManager ?
abrasssss[/quote]
Como o Leonardo3001 falou, se sua classe manager estiver chamando os DAOs diretamente, o código que controla transação deve estar dentro dela sim. Dessa forma, se a funcionalidade envolver uma chamada a dois ou mais DAOs para executar a persistência, eles estarão sendo usados dentro do mesmo contexto transacional.
