Possibilidades de design no uso do seu Generic DAO
3 minutos de leitura
Autor(a)
lucas
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
3 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Muitas vezes, quando estamos criando nosso sistema temos a tentação de criar o GenericDAO para não ter que ficar repetindo as operações CRUD e listagens.
O maior problema com o GenericDAO é que não necessariamente todas as operações fazem sentido para uma determinada classe. Daí o que fazer se, por exemplo, não faz sentido excluir um pagamento?
public class PagamentoDAO extends GenericDAO<Pagamento> { @Override public void excluir(Pagamento pagamento) { throw new UnsupportedOperationException(); } }
Não parece uma solução muito elegante, mas é um dos únicos jeitos de proibir uma operação declarada na classe mãe, e ainda assim, só funciona em tempo de execução. Esse é um dos principais motivos para muitos não gostarem de usar o GenericDAO e preferirem usar composição ao invés de herança. Mas como fazer para não repetir o código trivial das operações do CRUD?
Um dos jeitos é usar uma outra abstração de persistência de objetos: o Repository. Com o Repository, temos um lugar onde podemos guardar e buscar por objetos, não importando como fazemos isso. O DAO já está muito ligado com armazenamento em banco de dados, e foi criado quando as operações do BD eram muito trabalhosas (em especial no JDBC).
E como juntar o Repository com o GenericDAO? O Repository pode ser definido, por exemplo, como uma interface, e aí podemos fazer o seguinte: se, para um pagamento, faz sentido apenas salvar e listar, mas não excluir, então criamos a interface:
public interface PagamentoRepository { void salva(Pagamento pagamento); Pagamento busca(Long id); List<Pagamento> lista(); }
E usamos o GenericDAO como implementação dessa interface:
class PagamentoDAO extends GenericDAO<Pagamento> implements PagamentoRepository { // implementacao extra }
E no nosso código de domínio "nunca" referenciaremos o PagamentoDAO, apenas o PagamentoRepository, assim mesmo que a implementação saiba fazer mais coisas, a interface só expõe as operações suportadas.
Se você usa Injeção de Dependências e algum framework que a suporta (como o VRaptor, Spring ou Java EE6), você pode deixar os _DAO_s apenas como infraestrutura, e usar os Repositories como interfaces públicas da sua aplicação:
public class PagamentoController { public PagamentoController(PagamentoRepository repository) { this.repository = repository; }
public void salva(Pagamento pagamento) { // validações e outras regras repository.salva(pagamento); } }
Ainda poderíamos melhorar o nome do nosso repositório para BaseDePagamentos, ContasAPagar ou ainda Pagamentos, evitando usar sufixos nas classes. Usando abstrações e padrões simples conseguimos evitar repetição de código sem perder a semântica e restrições das nossas classes de modelo, além de esconder detalhes de implementação.
Avalie este artigo
