Do DAO ao Facade
O artigo demonstra algumas formas de como implementar o padrão de projeto Data Access Object (DAO), bem como sua importância no desenvolvimento de um sistema. Também aborda a importância e os benefícios do uso do padrão Facade.
O artigo demonstra algumas formas de como implementar o padrão de projeto Data Access Object (DAO), bem como sua importância no desenvolvimento de um sistema. Também aborda a importância e os benefícios do uso do padrão Facade.
Em que situação o tema é útil:
O tema é útil para desenvolvedores que queiram iniciar a construção de projetos de forma mais organizada, o que irá facilitar a manutenção e atualizações no futuro. O uso de um padrão de projeto tem como princípio organizar e facilitar o desenvolvimento de sistemas. Com o uso do padrão DAO é possível organizar as classes referentes à persistência de dados, e com o uso do padrão Facade é possível dividir o sistema em camadas, diminuindo o acoplamento entre elas.
Resumo DevMan:
O artigo apresenta um estudo sobre os padrões de projeto Data Access Object (DAO) e Facade. Começa descrevendo o padrão DAO e demonstrando algumas formas de como implementá-lo em um sistema e o quanto é vantajoso e importante utilizá-lo. Em seguida são apresentados os principais benefícios do uso do padrão Facade, assim como quando ele pode ser utilizado e o quanto fácil é implementá-lo em um projeto.
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." [...] continue lendo...
Artigos relacionados
-
Artigo
-
Artigo
-
Artigo
-
Artigo
-
Artigo