Do DAO ao Facade - Revista Java Magazine 97

Na década de 70 foi criado por Christopher Alexander o que se considera o primeiro padrão de projeto (Design Patterns). Tais conceitos usados por Alexander passaram a ser aplicados na área da informática, e nasceram a partir daí, os primeiros padrões de projeto direcionados ao desenvolvimento de softwares. Padrões de projeto têm como objetivo aplicar soluções que possam resolver problemas recorrentes no desenvolvimento de sistemas.

Grande parte das aplicações desenvolvidas em Java que fazem uso de banco de dados utiliza algum tipo de persistência como o JDBC puro (veja a segunda edição da Easy Java Magazine, artigo Java Database Connectivity) ou algum Framework como o Hibernate (apresentado na quarta edição da Easy Java, no artigo Dominando o Hibernate). Utilizando qualquer um destes modos de persistência há um sério risco de emaranhar, misturar o código de interface visual com o de lógica de negócios mais o código da persistência de dados (CRUD). Para evitar que exista esse emaranhado no código foi criado o padrão de projeto DAO (Data Access Object / Objeto de Acesso a Dados). O DAO se tornou assim um dos padrões de projeto mais utilizados no desenvolvimento de aplicações de softwares e tem como finalidade separar as regras de acesso a banco de dados das regras de negócios e de interface com usuário ou qualquer outro tipo de classe que não tenha relevância alguma com as ações de persistência.

CRUD: A sigla tem origem na língua inglesa para Create, Retrieve, Update e Delete, em português teria o significado de Criar, Recuperar, Atualizar e Excluir. São as quatro operações básicas em um banco de dados.

Outro padrão sugerido para a separação das estruturas de um projeto é o Façade ou Facade, uma espécie de fachada que limita o conhecimento do cliente (Interface Visual) das partes do sistema referentes à lógica de negócio. O Facade é um padrão estrutural e está entre os 23 padrões de projeto do GoF (Gang of Four). Um dos grandes benefícios deste padrão é a considerável facilidade em implementá-lo. O Facade foi desenvolvido para evitar que códigos e regras de interface visual se misturassem com as regras de negócios e assim, tornasse o código complicado e de difícil manutenção. Com seu uso é possível reduzir a dependência entre as classes clientes e as classes de negócios bem como criar sistemas divididos em camadas.

Entende-se por padrão estrutural todo padrão de projeto que trata da associação entre classes e objetos.

O Padrão Data Access Object (DAO)

Quando se faz uso em um projeto do padrão DAO é por que existe a necessidade em separar as regras de negócios das regras de persistência de dados. O objetivo principal disto é promover o isolamento entre classes de objetivos distintos (persistência/negócio/interface) e a flexibilidade quando se deseja, por exemplo, utilizar diferentes SGBDs (Sistema Gerenciador de Banco de Dados). Anteriormente, quando não se fazia uso do padrão DAO, as aplicações eram codificadas de forma que as deixavam dependentes de um único banco de dados. Assim havia dificuldades como migrar o sistema e alterar parte do código relacionado a operações de CRUD e ainda existia uma forte dependência entre classes de negócios com classes de persistência. Muitas vezes regras de acesso a banco de dados eram programadas nas classes de interface com o usuário o que tornava tanto a ampliação do sistema como uma simples manutenção uma tarefa muito mais complexa.

O padrão DAO surge como solução para esses problemas de uma forma bem simples. Com ele todas as regras do mecanismo de persistência passam a ser mediadas por um objeto do tipo DAO. Toda a lógica de acesso e execução ao banco de dados é colocada dentro do objeto DAO e desta forma se cria um isolamento entre a API de persistência e as demais partes do sistema. As operações de CRUD passam então a ser de inteira responsabilidade do objeto DAO, isolando-as do resto da aplicação. É considerado uma boa prática implementar as classes e interfaces do DAO dentro de um pacote chamado dao. Todas essas classes e interfaces devem seguir o padrão de nomenclatura “XxxxDAO”, onde o prefixo “Xxxx” faz referência ao nome da classe de entidade que será persistida e o sufixo “DAO” indica que esta classe se refere a uma classe de persistência que utiliza o padrão Data Access Object.

Interface DAO

Para se fazer uso do padrão DAO em um sistema, é sugerido desenvolver uma interface independente ao invés de uma classe concreta. A ideia é colocar todas as funcionalidades de persistência de dados em um só local, tornando simples sua manutenção. Na maioria dos casos um DAO inclui métodos para inserir, selecionar, atualizar e excluir objetos de um banco de dados. Após definir os métodos das operações de CRUD na interface, ela deve ser implementada em classes concretas, mais específicas de DAO. Toda a classe de entidade que possui a necessidade de executar operações de CRUD deve ter sua própria classe de DAO específica. Por exemplo, uma classe de entidade Contato realiza suas operações com a base de dados através de uma classe do tipo DAO chamada de ContatoDao. Esta classe de DAO deve ser implementada com os métodos da interface IContatoDao ou de uma interface mais genérica, IDao. Dependendo de como se implementa o padrão DAO, é possível ter uma interface específica para cada classe concreta de DAO (Listagem 1) ou uma única interface, mais genérica, que pode ser usada para qualquer classe específica de DAO (Listagem 2).

Uma classe JavaBean, também conhecida como POJO (Plain Old Java Objects), possui um construtor, atributos privados e os métodos getters e setters públicos.

Classe de Entidade: é uma classe do tipo Bean que faz referência a uma entidade do banco de dados e cada instância desta entidade representa uma linha (registro ou tupla) na tabela (entidade).

package br.com.devmedia.project.dao.first;

import br.com.devmedia.project.entidades.Contato;

import br.com.devmedia.project.exception.DAOException;

import java.util.List;

"